James C. McPherson
2009-Jul-31 04:33 UTC
[zfs-discuss] article on btrfs, comparison with zfs
An introduction to btrfs, from somebody who used to work on ZFS: http://www.osnews.com/story/21920/A_Short_History_of_btrfs James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog Kernel Conference Australia - http://au.sun.com/sunnews/events/2009/kernel
James C. McPherson wrote:> An introduction to btrfs, from somebody who used to work on ZFS: > > http://www.osnews.com/story/21920/A_Short_History_of_btrfs >*very* interesting article.. Not sure why James didn''t directly link to it, but courteous of Valerie Aurora (formerly Henson) http://lwn.net/Articles/342892/
>> An introduction to btrfs, from somebody who used to work on ZFS: >> >> http://www.osnews.com/story/21920/A_Short_History_of_btrfs > *very* interesting article.. Not sure why James didn''t directly link to > it, but courteous of Valerie Aurora (formerly Henson) > > http://lwn.net/Articles/342892/I''m trying to understand the argument against the SLAB allocator approach. If I understood correctly how BTRFS allocates space, changing and deleting files may just punch randomly sized holes into the disk layout. How''s that better? Regards, -mg
Mario Goebbels wrote:>>> An introduction to btrfs, from somebody who used to work on ZFS: >>> >>> http://www.osnews.com/story/21920/A_Short_History_of_btrfs >> *very* interesting article.. Not sure why James didn''t directly link to >> it, but courteous of Valerie Aurora (formerly Henson) >> >> http://lwn.net/Articles/342892/ > > I''m trying to understand the argument against the SLAB allocator > approach. If I understood correctly how BTRFS allocates space, changing > and deleting files may just punch randomly sized holes into the disk > layout. How''s that better?It''s an interesting article, for sure. The core of the article is actually how a solution (b+trees with copy-on-write) found a problem (file systems). To answer the question, the article claims that reallocation is part of the normal process writing data: > Defragmentation is an ongoing process - repacking the items > efficiently is part of the normal code path preparing extents to be > written to disk. Doing checksums, reference counting, and other > assorted metadata busy-work on a per-extent basis reduces overhead > and makes new features (such as fast reverse mapping from an extent > to everything that references it) possible. It sure suggests what is happening, but I haven''t got a clue on how the above makes a difference. Translating this to the ZFS design, I guess it involves delaying the block layout to the actual txg i/o phase, while zfs already decides this when a block enters the txg, it''s layout has been decided already. This allows for blocks to be dumped into a slog device as soon as it is available. Cheers, Henk
"C. Bergstr?m" writes: > James C. McPherson wrote: > > An introduction to btrfs, from somebody who used to work on ZFS: > > > > http://www.osnews.com/story/21920/A_Short_History_of_btrfs > > > *very* interesting article.. Not sure why James didn''t directly link to > it, but courteous of Valerie Aurora (formerly Henson) > > http://lwn.net/Articles/342892/ > > In terms of the ZFS comparison, Valerie gets it wrong. ZFS allocates out of metaslabs and space maps which take arbitrary size as an argument : http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/metaslab.c#388 Further reading : http://blogs.sun.com/bonwick/entry/space_maps -r > > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Henk Langeveld writes: > Mario Goebbels wrote: > >>> An introduction to btrfs, from somebody who used to work on ZFS: > >>> > >>> http://www.osnews.com/story/21920/A_Short_History_of_btrfs > >> *very* interesting article.. Not sure why James didn''t directly link to > >> it, but courteous of Valerie Aurora (formerly Henson) > >> > >> http://lwn.net/Articles/342892/ > > > > I''m trying to understand the argument against the SLAB allocator > > approach. If I understood correctly how BTRFS allocates space, changing > > and deleting files may just punch randomly sized holes into the disk > > layout. How''s that better? > > It''s an interesting article, for sure. The core of the article is actually > how a solution (b+trees with copy-on-write) found a problem (file systems). > > To answer the question, the article claims that reallocation is part of the > normal process writing data: > > > Defragmentation is an ongoing process - repacking the items > > efficiently is part of the normal code path preparing extents to be > > written to disk. Doing checksums, reference counting, and other > > assorted metadata busy-work on a per-extent basis reduces overhead > > and makes new features (such as fast reverse mapping from an extent > > to everything that references it) possible. > > It sure suggests what is happening, but I haven''t got a clue on how the above > makes a difference. Translating this to the ZFS design, I guess it involves > delaying the block layout to the actual txg i/o phase, while zfs already > decides this when a block enters the txg, it''s layout has been decided already. > Henk, I don''t know what ''enters the txg'' exactly is but ZFS disk-block allocation is done in the ZIO pipeline at the latest possible time. > This allows for blocks to be dumped into a slog device as soon as it is available. > I''m not sure what this refers to. -r > Cheers, > Henk > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Roch wrote:> I don''t know what ''enters the txg'' exactly is but ZFS disk-block > allocation is done in the ZIO pipeline at the latest > possible time.Thanks Roch, I stand corrected in my assumptions. Cheers, Henk