Migration from the KQ Implementation

Steve Costaras stevecs at chaven.com
Thu May 5 09:56:16 EDT 2011

While I don't don a beard (grey or otherwise), and completely understand the need for recovery or alternative means to pull data from a FS to handle unexpected situations I think it should be clear that ZFS is actualy not much worse than the aggregate of it's comprising functions. Comparing it to a traditional file system (ufs, jfs, xfs, ext[1-4], et al) is not really apples to apples.

ZFS in essence is three items in one, a RAID layer (regardless if this is different than block type traditional raid it is doing the same function) so that can be compared to say metadevices (MD; svm; etc.); a logical volume manager (VxVM; lvm; svm; etc. ) and then your FS of choice. You are getting all three layers basically merged together so failures in any one of the functional aspects can all have the same effect (data not available). Add to this other options that make it even harder such as dedup and compression. Traditionally, each 'layer' could be operated on one at a time so you can address lower issues before getting to the higher functions. 

I've run into the same number of issues (minus spikes due to 'new fangled syndome from upper management') across pretty much all unixes the past 25+ years when you take into consideration and consolidate all the underlaying functions that comprise the same device as presented to user space use.

I would love to have more functionality as to recovery options in cases of failure but realistically it's not something that is high on the list as it's not something that exists anywhere else either. The bigger item would be forensic data carving tools to pull data from vdevs/zpools however with the dedup/compression options this is much harder and basically not feasible at all with encryption (or I haven't seen anyone even try to attack that problem yet).

Remember what ZFS is (data/block availability and integrity) but not a solution for backups.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.zfsonlinux.org/pipermail/zfs-discuss/attachments/20110505/308ca051/attachment.html>

More information about the zfs-discuss mailing list