Comments on: Churning Butter(FS): An Interview with Chris Mason http://www.linux-mag.com/id/7329/ Open Source, Open Standards Sat, 05 Oct 2013 13:48:18 +0000 hourly 1 http://wordpress.org/?v=3.1 By: izzat http://www.linux-mag.com/id/7329/#comment-280401 izzat Fri, 13 Jul 2012 21:33:19 +0000 http://www.linux-mag.com/id/7329/#comment-280401 apple flash+603 2179 6838 apple flash+603 2179 6838

]]> By: izzat http://www.linux-mag.com/id/7329/#comment-280399 izzat Fri, 13 Jul 2012 21:32:23 +0000 http://www.linux-mag.com/id/7329/#comment-280399 apple flash apple flash

]]> By: ttsiodras http://www.linux-mag.com/id/7329/#comment-6434 ttsiodras Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7329/#comment-6434 I appreciate the efforts involved in creating BTRFS - Linux *needs* a copy-on-write FS.<br /> <br /> In the company I work for, we are already using ZFS (via OpenSolaris) to create practically unlimited daily backups of our virtual machines (huge VMWARE server .vmdk files that only differ daily in less than 1% of their data - only a copy-on-write fs could handle this well). The only problem I see with BTRFS is that it will take quite some time before we will be able to trust it as much as ZFS... Filesystems need a lot of time to iron out obscure race-conditions and rare usage patterns... I hope BTRFS will catch up quickly... and I feel good about Oracle owning both of them - no danger of patent wars on BTRFS! I appreciate the efforts involved in creating BTRFS – Linux *needs* a copy-on-write FS.

In the company I work for, we are already using ZFS (via OpenSolaris) to create practically unlimited daily backups of our virtual machines (huge VMWARE server .vmdk files that only differ daily in less than 1% of their data – only a copy-on-write fs could handle this well). The only problem I see with BTRFS is that it will take quite some time before we will be able to trust it as much as ZFS… Filesystems need a lot of time to iron out obscure race-conditions and rare usage patterns… I hope BTRFS will catch up quickly… and I feel good about Oracle owning both of them – no danger of patent wars on BTRFS!

]]> By: dog http://www.linux-mag.com/id/7329/#comment-6435 dog Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7329/#comment-6435 how long did you wait to trust ZFS? Its not that old. And Oracle owns btrfs? how long did you wait to trust ZFS? Its not that old. And Oracle owns btrfs?

]]> By: neondiet http://www.linux-mag.com/id/7329/#comment-6436 neondiet Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7329/#comment-6436 Is it possible with a raid10 filesystem to control which devices contain which halves of the mirror? I'll give you an example of why I'm asking. I've previously build raid10 volumes on HP-UX. HP's implementation of LVM includes a feature called Physical Volume Groups. Disks can be included in an LVM VG and then bunched into PVGs so that when creating a mirrored LV the mirror is split across PVGs. On systems with dual raid cards this has allowed me to put all the disks attached to one raid card in one PVG and disks attached to the other in a second PVG. The result is that I/O to a mirrored LV gets split evenly between both raid cards, doubling up the available bandwidth. In addition, it protects my LVs from a complete single raid controller failure. To achieve the same result on Linux today I must first use md to mirror devices across raid cards before adding the md devices to an LVM VG. Then I create LVs as normal and leave the mirroring down to md to sort out. It's a perfectly workable solution, but given that the ultimate goal of btrfs is to make md redundant, will we be able to achieve the same result in btrfs somehow? The wiki (linked in the article) doesn't hint at this. Thanks. Is it possible with a raid10 filesystem to control which devices contain which halves of the mirror? I’ll give you an example of why I’m asking. I’ve previously build raid10 volumes on HP-UX. HP’s implementation of LVM includes a feature called Physical Volume Groups. Disks can be included in an LVM VG and then bunched into PVGs so that when creating a mirrored LV the mirror is split across PVGs. On systems with dual raid cards this has allowed me to put all the disks attached to one raid card in one PVG and disks attached to the other in a second PVG. The result is that I/O to a mirrored LV gets split evenly between both raid cards, doubling up the available bandwidth. In addition, it protects my LVs from a complete single raid controller failure. To achieve the same result on Linux today I must first use md to mirror devices across raid cards before adding the md devices to an LVM VG. Then I create LVs as normal and leave the mirroring down to md to sort out. It’s a perfectly workable solution, but given that the ultimate goal of btrfs is to make md redundant, will we be able to achieve the same result in btrfs somehow? The wiki (linked in the article) doesn’t hint at this. Thanks.

]]> By: bugmenot http://www.linux-mag.com/id/7329/#comment-6437 bugmenot Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7329/#comment-6437 ZFS has been in Solaris for almost 3 years now, and it was in OpenSolaris before that. ZFS has been in Solaris for almost 3 years now, and it was in OpenSolaris before that.

]]> By: liotier http://www.linux-mag.com/id/7329/#comment-6438 liotier Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7329/#comment-6438 <blockquote cite="Article">Devices can be mixed in size and speed, and over the long term Btrfs will do the right thing to optimize access</blockquote><br /> <br /> You mean that the user can throw a motley mix of whatever he has, including devices of wildly different performance profiles such as hard disks and SSD, and that Btrfs will allocate data to the right device according to file size, block size and whatever other parameters may be relevant to it ? Would that be a sort of integrated hierarchical file system with data moving according to usage patterns ? Or simpler heuristics such as storing small files on low latency / low throughput devices such as SSD and large files on high latency / high throughput devices such as hard disks ? I find the "do the right thing" quote intriguing.

Devices can be mixed in size and speed, and over the long term Btrfs will do the right thing to optimize access

You mean that the user can throw a motley mix of whatever he has, including devices of wildly different performance profiles such as hard disks and SSD, and that Btrfs will allocate data to the right device according to file size, block size and whatever other parameters may be relevant to it ? Would that be a sort of integrated hierarchical file system with data moving according to usage patterns ? Or simpler heuristics such as storing small files on low latency / low throughput devices such as SSD and large files on high latency / high throughput devices such as hard disks ? I find the “do the right thing” quote intriguing.

]]> By: brmiller0423 http://www.linux-mag.com/id/7329/#comment-6439 brmiller0423 Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7329/#comment-6439 I have been trying to educate myself about RAID but have never actually set up a RAID configuration.<br /> <br /> When you speak of RAID 10, are you referring to "traditional" RAID 1+0, or to Linux MD RAID 10? Wikipedia offers a useful explanation: <a href="http://en.wikipedia.org/wiki/Non-standard_RAID_levels" rel="nofollow">. The kernel.org wiki which you refer to includes the sentence that "Raid10 requires at least 4 devices." which implies that you mean RAID 1+0.<br /> <br /> Would it not be more beneficial to the community to implement Linux MD RAID 10 before implementing RAID 5 and 6? I have been trying to educate myself about RAID but have never actually set up a RAID configuration.

When you speak of RAID 10, are you referring to “traditional” RAID 1+0, or to Linux MD RAID 10? Wikipedia offers a useful explanation: . The kernel.org wiki which you refer to includes the sentence that “Raid10 requires at least 4 devices.” which implies that you mean RAID 1+0.

Would it not be more beneficial to the community to implement Linux MD RAID 10 before implementing RAID 5 and 6?

]]> By: brmiller0423 http://www.linux-mag.com/id/7329/#comment-6440 brmiller0423 Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7329/#comment-6440 Sorry for snafu in previous post. Here's wishing that the site administrator implements a preview and/or a delete by author function.<br /> <br /> I have been trying to educate myself about RAID but have never actually set up a RAID configuration.<br /> <br /> When you speak of RAID 10, are you referring to “traditional” RAID 1+0, or to Linux MD RAID 10? Wikipedia offers a useful explanation: <a href="http://en.wikipedia.org/wiki/Non-standard_RAID_levels" title="Non-standard RAID levels" rel="nofollow">. The kernel.org wiki which you refer to includes the sentence that “Raid10 requires at least 4 devices.” which implies that you mean RAID 1+0.<br /> <br /> Would it not be more beneficial to the community to implement Linux MD RAID 10 before implementing RAID 5 and 6? Sorry for snafu in previous post. Here’s wishing that the site administrator implements a preview and/or a delete by author function.

I have been trying to educate myself about RAID but have never actually set up a RAID configuration.

When you speak of RAID 10, are you referring to “traditional” RAID 1+0, or to Linux MD RAID 10? Wikipedia offers a useful explanation: . The kernel.org wiki which you refer to includes the sentence that “Raid10 requires at least 4 devices.” which implies that you mean RAID 1+0.

Would it not be more beneficial to the community to implement Linux MD RAID 10 before implementing RAID 5 and 6?

]]> By: laytonjb http://www.linux-mag.com/id/7329/#comment-6441 laytonjb Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7329/#comment-6441 From what I've been reading, ZFS development began almost 6-8 years ago. As ttsiodras pointed out, it takes a long time for people to trust data to new file systems. This is also true for ZFS. It's taken 6-8 years to get people to trust ZFS enough to start using it. <br /> <br /> I think the same will be true for btrfs. It's only been in development 1-2 years so it will take some more time before it becomes accepted for critical data. I'm hopeful, however, because not only do we have Oracle behind it but also a great deal of the Linux community including many of the "heavy hitters". I may even go out on a limb and say that within 2 years btrfs will become much more accepted on Linux systems (but I will say that my track record on bets such as these isn't the best).<br /> <br /> But overall it's not a race. From what I’ve been reading, ZFS development began almost 6-8 years ago. As ttsiodras pointed out, it takes a long time for people to trust data to new file systems. This is also true for ZFS. It’s taken 6-8 years to get people to trust ZFS enough to start using it.

I think the same will be true for btrfs. It’s only been in development 1-2 years so it will take some more time before it becomes accepted for critical data. I’m hopeful, however, because not only do we have Oracle behind it but also a great deal of the Linux community including many of the “heavy hitters”. I may even go out on a limb and say that within 2 years btrfs will become much more accepted on Linux systems (but I will say that my track record on bets such as these isn’t the best).

But overall it’s not a race.

]]> By: laytonjb http://www.linux-mag.com/id/7329/#comment-6442 laytonjb Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7329/#comment-6442 I'm not sure to be honest. I think you can do this by using LVM first to create the two PVG's and then build btrfs on top of that.<br /> <br /> This might be a good question for the btrfs mailing list. In fact it's early enough that you could influence features. :) I’m not sure to be honest. I think you can do this by using LVM first to create the two PVG’s and then build btrfs on top of that.

This might be a good question for the btrfs mailing list. In fact it’s early enough that you could influence features. :)

]]>