Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
As you see I haven't studied XFS in depth, but I was under the impression it was COW like ZFS. AFAIK, WAFL also lacks the more interesting features of ZFS (foremost being end-to-end checksumming).
ZFS and WAFL
Posted Jun 17, 2007 17:29 UTC (Sun) by joern (subscriber, #22392)
Either way you have an incompatible format change. But the amount of code affected if rather small. Took about 1-2% of the effort to design a new filesystem in the LogFS case.
Posted Jun 17, 2007 18:06 UTC (Sun) by qu1j0t3 (guest, #25786)
Maybe so, but there's quite a lot of catch-up to do. Once you have COW, transactions, and checksums, then you want self-healing; then snapshots; pools; quotas; compression; and so on, until you eventually have something like ZFS. :)
Linus' grandstanding aside, it's possible there is quiet work going on to improve the situation, as David Magda commented on zfs-discuss:
Somewhat off topic, but it seems that someone released a COW file system for Linux (currently in 'alpha'):
* Extent based file storage (2^64 max file size)
* Space efficient packing of small files
* Space efficient indexed directories
* Dynamic inode allocation
* Writable snapshots
* Subvolumes (separate internal filesystem roots)
- Object level mirroring and striping
* Checksums on data and metadata (multiple algorithms available)
- Strong integration with device mapper for multiple device support
- Online filesystem check
* Very fast offline filesystem check
- Efficient incremental backup and FS mirroring
Via Storage Mojo
Posted Jun 17, 2007 19:05 UTC (Sun) by joern (subscriber, #22392)
Sure, ZFS has an impressive set of features. If nothing else, it has showed how things can be done. And I have little doubt that btrfs, which you quoted, will end up having most of those features relatively soon. And even if Chris dies tomorrow, I'll keep working on LogFS.
The only question is when, not if. :)
good to hear
Posted Jun 17, 2007 19:15 UTC (Sun) by qu1j0t3 (guest, #25786)
The only question is when, not if. :)
From comments I've heard, and the buzz around Linus' and Jon's posts, there seems to be considerable community interest around ZFS (I don't want to use anything else, or wait, so I switched to Solaris 10 some time ago).
Look forward to more news on this front. Did you follow-up on LKML? (I have not checked :)
Posted Jun 17, 2007 21:43 UTC (Sun) by joern (subscriber, #22392)
> Look forward to more news on this front. Did you follow-up on LKML? (I have not checked :)
My personal interest is in flash, not hard disks. Therefore ZFS is impressive technology, but solving someone else's problem. It is not the last word in filesystems either, as the fsck will run for hours or days if it ever becomes necessary. So there remain valid reasons to work on different filesystems.
Impressive technology none the less.
COW for Flash?
Posted Jun 18, 2007 17:26 UTC (Mon) by qu1j0t3 (guest, #25786)
It has been said that COW is ideal for Flash. Can you explain why ZFS isn't relevant here?
There is no fsck; ZFS is "always consistent on disk" (through COW+atomic transactions). It seems to me this is a necessary invariant to achieve its other features (such as snapshots). Debate flares up (occasionally) as to whether a scavenger will be necessary. If so, it won't much resemble 'fsck' - and certainly won't be run in normal operation or after reset/powerfail/etc (ZFS behaviour under impromptu reset is extremely well tested).
I suspect, but correct me if I'm wrong, once you "know" you've lost data in ZFS (through exhausting redundancy or ditto blocks), it's actually gone by definition, and unrecoverable by re-creating links. No doubt Bonwick et all have explained it better somewhere...
Posted Jun 19, 2007 8:17 UTC (Tue) by joern (subscriber, #22392)
Raw flash behaves sufficiently different to hard disks that some ZFS design assumptions become untrue. Flash has large erase blocks. Within erase blocks, data must be written from front to back. Writing the block again requires erasing all of it. So the filesystem block size either has to be equal to the erase block size, or you need garbage collection. And with garbage collection comes a nasty deadlock problem most people don't even realize exists. :)
Next comes wear out and protection against it. Afaics, ZFS has several hot zones that receive significantly more writes than others.
I guess those two are the big reasons.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds