On Tuesday, January 25, 2011 18:59:39 Freddie Cash wrote: > On Tue, Jan 25, 2011 at 9:43 AM, Hubert Kario <h...@qbs.com.pl> wrote: > > Besides, I don't see *why* this should be done... > > > > And as far as I know ZFS doesn't support different reduncancy levels for > > different files residing in the same directory. You can have > > ~/1billion$-project.tar.gz with triple redundancy and ~/temp.video.mkv > > with no reduncancy with btrfs... > > With ZFS, redundancy (mirror, raidz1, raidz2, raidz3) is done at the > storage pool layer, and affects the entire pool. You can mix and > match redundancy levels (combine mirror vdevs and raidz vdevs in the > same pool), but there's no way to control what data blocks go to which > vdev, as it's all just one giant pool of storage. > > However, there is a "copies" property for each filesystem that affects > how many copies of data blocks are stored, to increase the redundancy > for that filesystem. For example, you can create a storage pool using > 2 mirror vdevs (4 drives; equivalent to a RAID10 setup); then create a > filesystem with copies=2. Thus, any blocks written to that filesystem > will be stored twice, each of which is then striped across the two > vdevs, and then mirrored to each disk in the vdevs, potentially > leading to 4 (or more) blocks of data written to disk. > > This is similar to using Linux md to create RAID arrays underneath LVM > volume groups. The redundancy is managed via md; the filesystems just > see a collection of blocks to write to. > > The big difference (from what I understand) between ZFS and Btrfs is > the layering. ZFS separate storage management from filesystem > management, so redundancy happens at lower layers and the filesystem > just sends blocks to the pool. Whereas Btrfs combines them into one, > so that redundancy is managed at the filesystem level and can be > changed on a per-directory (or per-sub-volume?) basis, with the > filesystem handling the writes and the redundancy.
Right now you can't change the raid level at all but there are hooks planned to enable selecting raid level on a per file basis. btrfs allows for better management of space ond less over provisioning. So I'd say that management of storage space with btrfs is even easier than with ZFS: admin sets the default redundancy level for whole file system (let's say that it's a 4 disk system) to a RAID1 with two copies. After seting up the system sets the redundancy level in directories with databases to RAID10 Users storing big files use RAID5 for some files. one of the drives fails, admin removes the drive from set, schedules reballance. the set is smaller but all reduncancy is preserved New drives arrive, they are added to fs. FS is reballanced for the second time to achive better performance (the space would be usable even without it). > I don't pretend to understand all the intricacies of how Btrfs works > (I'm working on it), but the layering in ZFS is very nice and easy to > work with in comparison. Interesting how ZFS is considered the > "rampant layering violation", though. ;) :) :D btrfs is much simpler from user point of view :) as for rampant layering violation: most of the code that deals with stored data isn't concerned with raid level, in contrast with zfs. In other words, its in the code, not interface. -- Hubert Kario QBS - Quality Business Software 02-656 Warszawa, ul. Ksawerów 30/85 tel. +48 (22) 646-61-51, 646-74-24 www.qbs.com.pl -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
