Hello all, I recently checked out btrfs and have started putting it through its paces. I tried a raid10 and then a raid1, as so: mkfs.btrfs -m raid10 -d raid10 /dev/sda5 /dev/sdb5 /dev/sdc5 /dev/sdd5 and mkfs.btrfs -m raid1 -d raid1 /dev/sda5 /dev/sdb5 /dev/sdc5 /dev/sdd5 In both cases after mounting /dev/sda5 /mnt, df -h reported 4 * partition size. Is df lying, or is replication not happening right now? I also noticed that when I copied a file on to /mnt, I had to sync before the available file size was affected. Also, I did not read or write much, but only the first two disks /dev/sda5 and /dev/sdb5 had their access lights going while I was using -m raid1 and -d raid1. Is there any case where the third and fourth disks would be used with -m raid1 -d raid1? I''ve been writing Copy-On-Write software for a while now and believe strongly that it is "the right way" to do almost all data operations. There are manifest benefits in the filesystem domain for users, and am glad to see such an amazingly slick & easy to use competitor appear on the scene. I look forward to btrfs becoming disk format stable so I can more wholeheartedly embrace it. I spent quite a few hours late last night playing with Linux raid10 and ext4; setting stride and stripe sizes. Tonight I briefly toyed with btrfs and found it to be a far more pleasurable experience, and I got considerably higher performance metrics (using simple bonnie++ pleasurements). My CPU usage is considerably higher, but I find that I dont mind that knowing there is real consistency checking ongoing. Thank you all for this great effort. rektide -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2008-10-16 at 04:12 -0400, rektide wrote:> Hello all, > > I recently checked out btrfs and have started putting it through its > paces. I tried a raid10 and then a raid1, as so: > > mkfs.btrfs -m raid10 -d raid10 /dev/sda5 /dev/sdb5 /dev/sdc5 /dev/sdd5 > > and > > mkfs.btrfs -m raid1 -d raid1 /dev/sda5 /dev/sdb5 /dev/sdc5 /dev/sdd5 > > > In both cases after mounting /dev/sda5 /mnt, df -h reported 4 * > partition size. Is df lying, or is replication not happening right > now?df is lying. The total bytes in the FS include all 4 drives. I need to fix up the math for the total available space.> I also noticed that when I copied a file on to /mnt, I had to > sync before the available file size was affected.You mean in df? The delayed allocation accounting should be taking care of that, I''ll take a look.> Also, I did not > read or write much, but only the first two disks /dev/sda5 and > /dev/sdb5 had their access lights going while I was using -m raid1 and > -d raid1. Is there any case where the third and fourth disks would be > used with -m raid1 -d raid1? >Yes, it allocates in chunks of about 1GB. So if you wrote more than 1GB, the next two drives would have been used.> > I''ve been writing Copy-On-Write software for a while now and believe > strongly that it is "the right way" to do almost all data operations. > There are manifest benefits in the filesystem domain for users, and am > glad to see such an amazingly slick & easy to use competitor appear on > the scene. I look forward to btrfs becoming disk format stable so I > can more wholeheartedly embrace it. > > > I spent quite a few hours late last night playing with Linux raid10 > and ext4; setting stride and stripe sizes. Tonight I briefly toyed > with btrfs and found it to be a far more pleasurable experience, and I > got considerably higher performance metrics (using simple bonnie++ > pleasurements). My CPU usage is considerably higher, but I find that > I dont mind that knowing there is real consistency checking ongoing. > > > Thank you all for this great effort.Thanks for giving things a try and sending along these notes, I''m glad it worked well for you. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2008-10-16 at 04:12 -0400, rektide wrote:> Is there any case where the third and fourth disks would be > used with -m raid1 -d raid1?Perhaps when the first pair of disks fill up? I don''t know. I''m new here. Cheers, Eric
On Thu, Oct 16, 2008 at 2:32 PM, Eric Anopolsky <erpo41@gmail.com> wrote:> On Thu, 2008-10-16 at 04:12 -0400, rektide wrote: >> Is there any case where the third and fourth disks would be >> used with -m raid1 -d raid1? > > Perhaps when the first pair of disks fill up? I don''t know. I''m new > here.I didn''t check the code, that would be kind of a "linear append".. which is dump.... I was expecting a raid1 with 4 discs, to have exactly 3 copies of the original data, with each disk being a complete mirror. If we only have 1 copy (plus original), and therefore use only 2 disks for any individual write, probably, if we generate enough write load to make a couple of disks busy, it will use the second couple of disks also. Basically, the allocator should be able to balance the write load, and spread allocations to all devices.. however.. if the write load is insuficient to saturate a single pair of devices, there''s no point in using the second pair.. it would just make the machine burn more watts This is pure speculation... Best thing is to look at the code. :) Kind regards, -- Miguel Sousa Filipe -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html