This project has moved and is read-only. For the latest updates, please go here.

The far future of Liquesce

Sep 11, 2010 at 9:39 PM

I know that it is very early to discuss this toppic but the thing is, I can't imagine why nobody has implemented such a feature...

I think most of you are knowing FlexRAID. It's really cool but it has some limitations in dependability. A fact is that a snapshot RAID won't be able to rebuild all data if there were file changes since the last snapshot


For my understanding Liquesce stands between the NTFS presentation of the pysical drives and the windows kernel presentation as one disk. This should be exactly the point where a checksum generation would make sence. Let me describe why...

1.) It is the point where you know which files are landing on which disk.

2.) It recognizes every filechange (if the physical disks are hidden) so the parity could be generated live.

This is how RAIDZ of zfs`basicly works and from the theoretical point of view you only need the largest disk for parity to have a complete one disk fault tollerance. The problem with RAIDZ is, that it isn't possible to add or remove disks easily from the pool. You always have to backup the data and rebuild the RAIDZ.

If only one disk would be used for parity it should be easy to rebuild the parity if a disk is added or removed. And again... Liquesce should recognize if something has changed.

The nowerdays multicore cpus should have no problem with the parity calculation and I'm not sure but I think a data communication is already done over the cpu in Liquesce so instead of writing to one disk it would be writing on two disks (data and parity).

So why not add a checksum to an additional drive? (it sounds so easy ;) ) It would be a super flexible pseudo RAID :-D


By the way... I think there are some products which are doing what I discribed but they are only NAS implementations like drobo and others. Why not learning windows the same features?

Sep 12, 2010 at 9:32 AM

I do have some plans for a RAID style thing, but it wasn't going to use the Liquesce as a Must have.

e.g. you yourself have hinted at multiple shares, would this mean multiple Raid engines as well..

Not sure that fits for the initial design.

So was / may (Time thing) going to write a seperate engine, that could attach to the Liquesce service (Re-using the interface necessary for the Tray application) that would then be notified of things going on, just in case the OS had not informed the .Net FileWatchers (Apperently not that reliable !) that something had gone on, then regardless of the number of mount points, the engine could still utilise a parity drive.

Also it keeps the file access seperate in case the Liquesce mount is being used for something intensive like creating a movie file, from MKVMerge..

Jan 23, 2011 at 8:35 PM

I hope the project is still actually active.

We haven't seen much development-wise lately.


Jan 24, 2011 at 11:43 AM

As only 3 poepole have downloaded the aplha that uses Dokan 0.6.0 ( I see little progress..

Also I have been testing platforms and come across some issues that will need to be resolved / proved in the Dokan driver.

And; I have been working week ends to solve WIX issues with IIS 7.5 and 32 bit dll's !! (That still have to work on XP onwards !!)

Jan 24, 2011 at 12:21 PM

Thanks for the update. Give time for the Alpha.

I plan on keeping update status of Liquesce and FlexRAID progress on my blog, so possibly some geeks will be tempted to try it too.


Jan 26, 2011 at 12:42 AM
smurfiv wrote:

Also I have been testing platforms and come across some issues that will need to be resolved / proved in the Dokan driver.

Yeah it does seem to have issues... what have you found?

Jan 26, 2011 at 7:09 AM seems to be the big one at the moment.

Had little time to see if it's the example code, my code, An OS setup issue or something else.

Also the code checkin's for Dokan have stopped again !

Feb 9, 2011 at 10:14 AM

Not so great.

The guy that maintains Dokan is like someone we know eh?