Re: TUX2 filesystem
On Thu, 21 June 2007 13:57:15 -0400, James Bruce wrote: > > efficient atomic snapshots on a filesystem. There are still some issues > with unexpected disk space usage (it requires _additional_ disk space to > _delete_ a file), and it tends to use more memory (you want to delay > client writes as much as possible, so you can allocate later and copy > the least amount necessary) The delete issue really surprised me. It is so obvious and simple to solve that it hardly deserves mentioning. And yet ZFS allegedly hasn't solved it yet - scary. Additional memory isn't strictly required either. It just helps to delay writes as long as possible to fight fragmentation. Jörn -- Joern's library part 9: http://www.scl.ameslab.gov/Publications/Gus/TwelveWays.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: TUX2 filesystem
On Thu, 21 June 2007 13:57:15 -0400, James Bruce wrote: efficient atomic snapshots on a filesystem. There are still some issues with unexpected disk space usage (it requires _additional_ disk space to _delete_ a file), and it tends to use more memory (you want to delay client writes as much as possible, so you can allocate later and copy the least amount necessary) The delete issue really surprised me. It is so obvious and simple to solve that it hardly deserves mentioning. And yet ZFS allegedly hasn't solved it yet - scary. Additional memory isn't strictly required either. It just helps to delay writes as long as possible to fight fragmentation. Jörn -- Joern's library part 9: http://www.scl.ameslab.gov/Publications/Gus/TwelveWays.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: TUX2 filesystem
On Thu, Jun 21, 2007 at 03:26:15PM -0700, Zach Brown wrote: > > Second, Oracle is now working on Btrfs (if ever a FS needed a better > > name... is that pronounced ButterFS?). > > (In our silliest moments, yes. Absolutely.) I'm sure when the PHBen are around it's "Better FS". It's all a Free(software)Mason conspiracy, I tell you. Bron. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: TUX2 filesystem
> Second, Oracle is now working on Btrfs (if ever a FS needed a better > name... is that pronounced ButterFS?). (In our silliest moments, yes. Absolutely.) - z - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: TUX2 filesystem
Hi, Ph. Marek wrote: in Oct 2000 there's been some discussion "Tux2 - evil patents sighted" (http://www.ussg.iu.edu/hypermail/linux/kernel/0010.0/0343.html), and in Aug 2002 (http://www.uwsg.iu.edu/hypermail/linux/kernel/0208.3/0332.html) Daniel wrote It's well down my list of priorities because of uncertainties due to the U.S. patent system. Does anybody want to know if patent chill exists, and is it hurting open source? The answer is yes. I'm surprised this didn't come up sooner, but the situation is a little different now. First, Sun is pushing ZFS quite a lot, even though it appears to violate pretty much all of Network Appliance's patents (ZFS is really not that much more than WAFL + extents + checksums AFAICT). Considering ZFS will be in Solaris, BSD, and MacOS, perhaps Sun feels that it is calling NA's bluff on the validity of the WAFL patents. Second, Oracle is now working on Btrfs (if ever a FS needed a better name... is that pronounced ButterFS?). Like Daniel pointed out when doing Tux2, the "hierarchical copy on write" approach used in WAFL, ZFS, Tux2 and Btrfs is _not_ that new of an idea in the database world. Maybe Oracle feels they can push out Btrfs because they have some prior art, or just that they have enough of a patent arsenal to keep NA from challenging them. So, it is clear why individual developers and Ext* people would steer away from the NA patents, but large companies may not have to. The recent US supreme court ruling may have helped out in that regard. It seems to me that this kind of filesystem could solve a few problems that are currently attacked: - Atomic snapshots. Make a new superblock, and mount this copy in another directory. As long as it's not overwritten, it stays consistent. - Speed/Consistency for Flash media. There is a list of superblocks, and when the new block has been written the pointer from the old gets set - until the first block in the list gets re-written. It's been pretty clear at least in the research world that this is *the* approach if you want atomic snapshots. COW is the obvious and sane way to do that, and file systems are trees, so COW on a tree is how you do efficient atomic snapshots on a filesystem. There are still some issues with unexpected disk space usage (it requires _additional_ disk space to _delete_ a file), and it tends to use more memory (you want to delay client writes as much as possible, so you can allocate later and copy the least amount necessary), but once users wrap their heads around the concepts, many feel the benefits outweigh the drawbacks. If patents hadn't stood in the way, we'd have had this stuff years ago. At least there is some progress now, and better late than never. - Jim Bruce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: TUX2 filesystem
Hi, Ph. Marek wrote: in Oct 2000 there's been some discussion Tux2 - evil patents sighted (http://www.ussg.iu.edu/hypermail/linux/kernel/0010.0/0343.html), and in Aug 2002 (http://www.uwsg.iu.edu/hypermail/linux/kernel/0208.3/0332.html) Daniel wrote It's well down my list of priorities because of uncertainties due to the U.S. patent system. Does anybody want to know if patent chill exists, and is it hurting open source? The answer is yes. I'm surprised this didn't come up sooner, but the situation is a little different now. First, Sun is pushing ZFS quite a lot, even though it appears to violate pretty much all of Network Appliance's patents (ZFS is really not that much more than WAFL + extents + checksums AFAICT). Considering ZFS will be in Solaris, BSD, and MacOS, perhaps Sun feels that it is calling NA's bluff on the validity of the WAFL patents. Second, Oracle is now working on Btrfs (if ever a FS needed a better name... is that pronounced ButterFS?). Like Daniel pointed out when doing Tux2, the hierarchical copy on write approach used in WAFL, ZFS, Tux2 and Btrfs is _not_ that new of an idea in the database world. Maybe Oracle feels they can push out Btrfs because they have some prior art, or just that they have enough of a patent arsenal to keep NA from challenging them. So, it is clear why individual developers and Ext* people would steer away from the NA patents, but large companies may not have to. The recent US supreme court ruling may have helped out in that regard. It seems to me that this kind of filesystem could solve a few problems that are currently attacked: - Atomic snapshots. Make a new superblock, and mount this copy in another directory. As long as it's not overwritten, it stays consistent. - Speed/Consistency for Flash media. There is a list of superblocks, and when the new block has been written the pointer from the old gets set - until the first block in the list gets re-written. It's been pretty clear at least in the research world that this is *the* approach if you want atomic snapshots. COW is the obvious and sane way to do that, and file systems are trees, so COW on a tree is how you do efficient atomic snapshots on a filesystem. There are still some issues with unexpected disk space usage (it requires _additional_ disk space to _delete_ a file), and it tends to use more memory (you want to delay client writes as much as possible, so you can allocate later and copy the least amount necessary), but once users wrap their heads around the concepts, many feel the benefits outweigh the drawbacks. If patents hadn't stood in the way, we'd have had this stuff years ago. At least there is some progress now, and better late than never. - Jim Bruce - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: TUX2 filesystem
Second, Oracle is now working on Btrfs (if ever a FS needed a better name... is that pronounced ButterFS?). (In our silliest moments, yes. Absolutely.) - z - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: TUX2 filesystem
On Thu, Jun 21, 2007 at 03:26:15PM -0700, Zach Brown wrote: Second, Oracle is now working on Btrfs (if ever a FS needed a better name... is that pronounced ButterFS?). (In our silliest moments, yes. Absolutely.) I'm sure when the PHBen are around it's Better FS. It's all a Free(software)Mason conspiracy, I tell you. Bron. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
TUX2 filesystem
Hello Daniel, hello everbody else, in Oct 2000 there's been some discussion "Tux2 - evil patents sighted" (http://www.ussg.iu.edu/hypermail/linux/kernel/0010.0/0343.html), and in Aug 2002 (http://www.uwsg.iu.edu/hypermail/linux/kernel/0208.3/0332.html) Daniel wrote > It's well down my list of priorities because of uncertainties due to > the U.S. patent system. > Does anybody want to know if patent chill exists, and is it hurting > open source? The answer is yes. With the recent Supreme Court decisions (http://www.groklaw.net/article.php?story=20070430121005424) and the fact that Daniel wrote that he did most of his work in *1989* (which is now 18 years ago!) is there a chance for newer developments? It seems to me that this kind of filesystem could solve a few problems that are currently attacked: - Atomic snapshots. Make a new superblock, and mount this copy in another directory. As long as it's not overwritten, it stays consistent. - Speed/Consistency for Flash media. There is a list of superblocks, and when the new block has been written the pointer from the old gets set - until the first block in the list gets re-written. There may be some other nice things I didn't think about - but just having this filesystem for harddisks might be good, too. Regards, Phil - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
TUX2 filesystem
Hello Daniel, hello everbody else, in Oct 2000 there's been some discussion Tux2 - evil patents sighted (http://www.ussg.iu.edu/hypermail/linux/kernel/0010.0/0343.html), and in Aug 2002 (http://www.uwsg.iu.edu/hypermail/linux/kernel/0208.3/0332.html) Daniel wrote It's well down my list of priorities because of uncertainties due to the U.S. patent system. Does anybody want to know if patent chill exists, and is it hurting open source? The answer is yes. With the recent Supreme Court decisions (http://www.groklaw.net/article.php?story=20070430121005424) and the fact that Daniel wrote that he did most of his work in *1989* (which is now 18 years ago!) is there a chance for newer developments? It seems to me that this kind of filesystem could solve a few problems that are currently attacked: - Atomic snapshots. Make a new superblock, and mount this copy in another directory. As long as it's not overwritten, it stays consistent. - Speed/Consistency for Flash media. There is a list of superblocks, and when the new block has been written the pointer from the old gets set - until the first block in the list gets re-written. There may be some other nice things I didn't think about - but just having this filesystem for harddisks might be good, too. Regards, Phil - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
