Re: System completely unresponsive after `btrfs balance start -dconvert=raid0 /` and `btrfs fi show /`
Zygo Blaxell posted on Thu, 15 Oct 2015 00:39:27 -0400 as excerpted: > As others have pointed out, the raid0 allocator has a 2-disk-minimum > constraint, so any difference in size between the largest and > second-largest disk is unusable. In your case that's 73% of the raw > space. > > If the two smaller disks were almost full (no space unallocated in > 'btrfs fi usage') before you converted to raid0, then immediately after > starting a conversion to raid0 you have no space left _at all_. This is > because the space you previously had under some other data profile is no > longer considered "free" even if it isn't in use. All future > allocations must be raid0, starting immediately, but no space is > available for raid0 data chunks. > > This will cause some symptoms like huge write latency (it will not take > seconds or minutes, but *hours* to write anything to the disk) and > insanely high CPU usage. Very nice analysis. The implications hadn't occurred to me, but you spell them out in the stark terms the reality of the situation dictates, along with offering a sane way out. Thanks. I'll have to keep this in mind for the next time something like this comes up. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- 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
Re: System completely unresponsive after `btrfs balance start -dconvert=raid0 /` and `btrfs fi show /`
On Wed, Oct 14, 2015 at 05:08:17AM +, Duncan wrote: > Carmine Paolino posted on Tue, 13 Oct 2015 23:21:49 +0200 as excerpted: > > > I have an home server with 3 hard drives that I added to the same btrfs > > filesystem. Several hours ago I run `btrfs balance start -dconvert=raid0 > > /` and as soon as I run `btrfs fi show /` I lost my ssh connection to > > the machine. The machine is still on, but it doesn’t even respond to > > ping[. ...] > > > > (I have a 250gb internal hard drive, a 120gb usb 2.0 one and a 2TB usb > > 2.0 one so the transfer speeds are pretty low) > > I won't attempt to answer the primary question[1] directly, but can point > out that in many cases, USB-connected devices simply don't have a stable > enough connection to work reliably in a multi-device btrfs. There's > several possibilities for failure, including flaky connections (sometimes > assisted by cats or kids), unstable USB host port drivers, and unstable > USB/ATA translators. A number of folks have reported problems with such > filesystems with devices connected over USB, that simply disappear if > they direct-connect the exact same devices to a proper SATA port. The > problem seems to be /dramatically/ worse with USB connected devices, than > it is with, for instance, PCIE-based SATA expansion cards. > > Single-device btrfs with USB-attached devices seem to work rather better, > because at least in that case, if the connection is flaky, the entire > filesystem appears and disappears at once, and btrfs' COW, atomic-commit > and data-integrity features, kick in to help deal with the connection's > instability. > > Arguably, a two-device raid1 (both data/metadata, with metadata including > system) should work reasonably well too, as long as scrubs are done after > reconnection when there's trouble with one of the pair, because in that > case, all data appears on both devices, but single and raid0 modes are > likely to have severe issues in that sort of environment, because even > temporary disconnection of a single device means loss of access to some > data/metadata on the filesystem. Raid10, 3+-device-raid1, and raid5/6, > are more complex situations. They should survive loss of at least one > device, but keeping the filesystem healthy in the presence of unstable > connections is... complex enough I'd hate to be the one having to deal > with it, which means I can't recommend it to others, either. Note also that RAID-0 is a poor choice for this configuration, because you'll only get 640 GB usable space out of it. With single, you'll get the full sum of 2370 GB usable. With RAID-1, you'll have 320 GB usable. The low figures for the RAID-0 and -1 come from the fact that you've got two small devices, and that both RAID-0 and RAID-1 have a minimum of two devices per block group. You can play around with the configurations at http://carfax.org.uk/btrfs-usage But I second Duncan's advice about not using USB. It's really not a reliable configuration with btrfs. Hugo. > So I'd recommend either connecting all devices internally if possible, or > setting up the USB-connected devices with separate filesystems, if > internal direct-connection isn't possible. > > --- > [1] Sysadmin's rule of backups. If the data isn't backed up, by > definition it is of less value than the resource and hassle cost of > backup. No exceptions -- post-loss claims to the contrary simply put the > lie to the claims, as actions spoke louder than words and they defined > the cost of the backup as more expensive than the data that would have > been backed up. Worst-case is then loss of data that was by definition > of less value than the cost of backup, and the more valuable resource and > hassle cost of the backup was avoided, so the comparatively lower value > data loss is no big deal. > > So in a case like this, I'd simply power down and take my chances of > filesystem loss, strictly limiting the time and resources I'd devote to > any further attempt at recovery, because the data is by definition either > backed up, or of such low value that a backup was considered too > expensive to do, meaning there's a very real possibility of spending more > time in a recovery attempt that's iffy at best, than the data on the > filesystem is actually worth, either because there are backups, or > because it's throw-away data in the first place. > -- Hugo Mills | There's an infinite number of monkeys outside who hugo@... carfax.org.uk | want to talk to us about this new script for Hamlet http://carfax.org.uk/ | they've worked out! PGP: E2AB1DE4 | Arthur Dent signature.asc Description: Digital signature
Re: System completely unresponsive after `btrfs balance start -dconvert=raid0 /` and `btrfs fi show /`
Hugo Mills posted on Wed, 14 Oct 2015 09:13:25 + as excerpted: > On Wed, Oct 14, 2015 at 05:08:17AM +, Duncan wrote: >> Carmine Paolino posted on Tue, 13 Oct 2015 23:21:49 +0200 as excerpted: >> >> > I have an home server with 3 hard drives that I added to the same >> > btrfs filesystem. Several hours ago I run `btrfs balance start >> > -dconvert=raid0 /` and as soon as I run `btrfs fi show /` I lost my >> > ssh connection to the machine. The machine is still on, but it >> > doesn’t even respond to ping[. ...] >> > >> > (I have a 250gb internal hard drive, a 120gb usb 2.0 one and a 2TB >> > usb 2.0 one so the transfer speeds are pretty low) >> > >Note also that RAID-0 is a poor choice for this configuration, > because you'll only get 640 GB usable space out of it. With single, > you'll get the full sum of 2370 GB usable. With RAID-1, you'll have 320 > GB usable. The low figures for the RAID-0 and -1 come from the fact that > you've got two small devices, and that both RAID-0 and RAID-1 have a > minimum of two devices per block group. You can play around with the > configurations at http://carfax.org.uk/btrfs-usage Thanks, Hugo. I totally forgot about the sizing effects of raid0 with that sort of wide device mismatch, but you have a very good point as I can't imagine anyone limiting their space usage like that on purpose. Tho AFAIK the raid0 space available space would be 120*3 + (250-120)*2 = 360 + 130*2 = 360+260 = 620 GB? (Raid0 stripe 3 devices wide until the 120 gig device is full, 2 devices wide after that until the remainder of the 250 gig device is full, the rest of the 2 TB device unused as there's no second device available to raid0 stripe with.) In the event that a raid0 of the three is desired, I'd partition up the big 2 TB device with the partition for the raid0 being 250 GB, same as the second largest device, with the remaining ~1750 GB then being available for use as a single-device filesystem. Alternatively, one /could/ partition up the 2 TB device as eight 250 GB partitions, and add each of those separately to the raid0, thus letting the filesystem do 10-way raid0 striping on the first 120 GB, 9-way raid0 striping after that, tho 8 of those strips would actually be on partitions of the same physical device. It'd certainly be slow, but it'd use the available space on the 2 TB device, if that was the primary object. But single mode would certainly be more efficient, for sure. Meanwhile, raid0 in general, even totally apart from btrfs, should always be considered usable only for throw-away data, either because there's a backup or because it really is throw-away (I used to use mdraid0 on partitions for my distro's package repo and similar effective internet local cache data, for instance, where loss of the raid0 simply meant redownloading what it had cached), because with raid0, loss of a single device means loss of everything on the raid, so you've effectively multiplied the chance of failure by the number of physical devices in the raid0. So quite apart from the backups rule I mentioned earlier, raid0 really does mean throw-away data, not worth worrying about recovery. Raid0's primary use is simply speed, but across USB2, it can't even really be used for speed, so there's really no use for it at all, unless one is simply doing it "because they can" (like the raid0 of about 50 1.44 MB floppies I believe I watched a youtube video of, at one point, simply "because they can"!). Btrfs multi-device single mode (at least with single mode for metadata as well as data) isn't really better than raid0 in terms of reliability, but at least it lets you use the full capacity of the devices. (Btrfs raid1 metadata, single data, is the default for multi-device btrfs, and is at least in theory /somewhat/ more reliable than single-mode metadata, since at least in theory, a dropped device at least lets you recover anything that didn't happen to be on the bad device, but in practice I'd not recommend relying on that. Plan as if it was raid0 reliability -- loss of a single device means loss of the entire thing.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- 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
Re: System completely unresponsive after `btrfs balance start -dconvert=raid0 /` and `btrfs fi show /`
On Tue, Oct 13, 2015 at 11:21:49PM +0200, Carmine Paolino wrote: > I have an home server with 3 hard drives that I added to the same btrfs > filesystem. Several hours ago I run `btrfs balance start -dconvert=raid0 > /` and as soon as I run `btrfs fi show /` I lost my ssh connection to > the machine. The machine is still on, but it doesn’t even respond > to ping: I always get a request timeout and sometimes even an host > is down message. Its fans are spinning at full blast and the hard > drives’s led are registering activity all the time. I run Plex Home > Theater too there and the display output is stuck at the time when > I run those two commands. I left it running because I fear to lose > everything by powering it down manually. > > Should I leave it like this and let it finish? How long it might > take? (I have a 250gb internal hard drive, a 120gb usb 2.0 one and a > 2TB usb 2.0 one so the transfer speeds are pretty low) Is it safe to > power it off manually? Should I file a bug after it? As others have pointed out, the raid0 allocator has a 2-disk-minimum constraint, so any difference in size between the largest and second-largest disk is unusable. In your case that's 73% of the raw space. If the two smaller disks were almost full (no space unallocated in 'btrfs fi usage') before you converted to raid0, then immediately after starting a conversion to raid0 you have no space left _at all_. This is because the space you previously had under some other data profile is no longer considered "free" even if it isn't in use. All future allocations must be raid0, starting immediately, but no space is available for raid0 data chunks. This will cause some symptoms like huge write latency (it will not take seconds or minutes, but *hours* to write anything to the disk) and insanely high CPU usage. Normally btrfs gets slower exponentially as it gets full (this is arguably a performance bug), so you'll have plenty of opportunity to get the system under control before things get unusably slow. What you have done is somewhat different--you've gone all the way to zero free space all at once, but you still have lots of what _might_ be free space to search through when doing allocations. Now your CPU is spending all of its time searching everywhere for free space that isn't really there--and when it doesn't find any free space, it immediately starts the search over from scratch. If you're running root on this filesystem, it is likely that various daemons are trying to write data constantly, e.g. kernel log messages. Each of these writes, no matter how small, will take hours. Then the daemons will be trying to log the fact that writes are taking hours. Which will take hours. And so on. This flood of writes at nearly 20K per hour will overwhelm the tiny amount of bandwidth btrfs can accomodate in this condition. The way to get out of this is to mount the filesystem such that nothing is attempting to write to it (e.g. boot from rescue media). Mount the filesystem with the 'skip_balance' option, and do 'btrfs balance cancel /fs; btrfs balance start -dconvert=single,soft /fs'. Expect both commands to take several hours (maybe even days) to run. In theory, you can add another disk in order to enable raid0 allocations, but you have to mount the filesystem and stop the running balance before you can add any disks...and that will take hours anyway, so extra disks won't really help. If you can get a root shell and find the kworker threads that are spinning on your CPU, you can renice them. If you have RT priority processes in your system, some random kworkers will randomly acquire RT privileges. Random kworkers are used by btrfs, so when btrfs eats all your CPU it can block everything for minutes at a time. The kworkers obey the usual schedtool commands, e.g. 'schedtool -D -n20 -v ' to make them only run when the CPU is idle. > Any help would be appreciated. > > Thanks, > Carmine-- > 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 signature.asc Description: Digital signature
Re: System completely unresponsive after `btrfs balance start -dconvert=raid0 /` and `btrfs fi show /`
On 2015-10-14 05:13, Hugo Mills wrote: On Wed, Oct 14, 2015 at 05:08:17AM +, Duncan wrote: Carmine Paolino posted on Tue, 13 Oct 2015 23:21:49 +0200 as excerpted: I have an home server with 3 hard drives that I added to the same btrfs filesystem. Several hours ago I run `btrfs balance start -dconvert=raid0 /` and as soon as I run `btrfs fi show /` I lost my ssh connection to the machine. The machine is still on, but it doesn’t even respond to ping[. ...] (I have a 250gb internal hard drive, a 120gb usb 2.0 one and a 2TB usb 2.0 one so the transfer speeds are pretty low) I won't attempt to answer the primary question[1] directly, but can point out that in many cases, USB-connected devices simply don't have a stable enough connection to work reliably in a multi-device btrfs. There's several possibilities for failure, including flaky connections (sometimes assisted by cats or kids), unstable USB host port drivers, and unstable USB/ATA translators. A number of folks have reported problems with such filesystems with devices connected over USB, that simply disappear if they direct-connect the exact same devices to a proper SATA port. The problem seems to be /dramatically/ worse with USB connected devices, than it is with, for instance, PCIE-based SATA expansion cards. Single-device btrfs with USB-attached devices seem to work rather better, because at least in that case, if the connection is flaky, the entire filesystem appears and disappears at once, and btrfs' COW, atomic-commit and data-integrity features, kick in to help deal with the connection's instability. Arguably, a two-device raid1 (both data/metadata, with metadata including system) should work reasonably well too, as long as scrubs are done after reconnection when there's trouble with one of the pair, because in that case, all data appears on both devices, but single and raid0 modes are likely to have severe issues in that sort of environment, because even temporary disconnection of a single device means loss of access to some data/metadata on the filesystem. Raid10, 3+-device-raid1, and raid5/6, are more complex situations. They should survive loss of at least one device, but keeping the filesystem healthy in the presence of unstable connections is... complex enough I'd hate to be the one having to deal with it, which means I can't recommend it to others, either. Note also that RAID-0 is a poor choice for this configuration, because you'll only get 640 GB usable space out of it. With single, you'll get the full sum of 2370 GB usable. With RAID-1, you'll have 320 GB usable. The low figures for the RAID-0 and -1 come from the fact that you've got two small devices, and that both RAID-0 and RAID-1 have a minimum of two devices per block group. You can play around with the configurations at http://carfax.org.uk/btrfs-usage But I second Duncan's advice about not using USB. It's really not a reliable configuration with btrfs. I'd also second that statement, but go even further and say to not use USB for anything except backups and transferring data between computers unless you have absolutely no other option, and be wary of using any externally connected storage device for other use cases (I've seen similar issues with eSATA drives and BTRFS, and have heard of such issues with some Thunderbolt connected storage devices). smime.p7s Description: S/MIME Cryptographic Signature
Re: System completely unresponsive after `btrfs balance start -dconvert=raid0 /` and `btrfs fi show /`
Carmine Paolino posted on Tue, 13 Oct 2015 23:21:49 +0200 as excerpted: > I have an home server with 3 hard drives that I added to the same btrfs > filesystem. Several hours ago I run `btrfs balance start -dconvert=raid0 > /` and as soon as I run `btrfs fi show /` I lost my ssh connection to > the machine. The machine is still on, but it doesn’t even respond to > ping[. ...] > > (I have a 250gb internal hard drive, a 120gb usb 2.0 one and a 2TB usb > 2.0 one so the transfer speeds are pretty low) I won't attempt to answer the primary question[1] directly, but can point out that in many cases, USB-connected devices simply don't have a stable enough connection to work reliably in a multi-device btrfs. There's several possibilities for failure, including flaky connections (sometimes assisted by cats or kids), unstable USB host port drivers, and unstable USB/ATA translators. A number of folks have reported problems with such filesystems with devices connected over USB, that simply disappear if they direct-connect the exact same devices to a proper SATA port. The problem seems to be /dramatically/ worse with USB connected devices, than it is with, for instance, PCIE-based SATA expansion cards. Single-device btrfs with USB-attached devices seem to work rather better, because at least in that case, if the connection is flaky, the entire filesystem appears and disappears at once, and btrfs' COW, atomic-commit and data-integrity features, kick in to help deal with the connection's instability. Arguably, a two-device raid1 (both data/metadata, with metadata including system) should work reasonably well too, as long as scrubs are done after reconnection when there's trouble with one of the pair, because in that case, all data appears on both devices, but single and raid0 modes are likely to have severe issues in that sort of environment, because even temporary disconnection of a single device means loss of access to some data/metadata on the filesystem. Raid10, 3+-device-raid1, and raid5/6, are more complex situations. They should survive loss of at least one device, but keeping the filesystem healthy in the presence of unstable connections is... complex enough I'd hate to be the one having to deal with it, which means I can't recommend it to others, either. So I'd recommend either connecting all devices internally if possible, or setting up the USB-connected devices with separate filesystems, if internal direct-connection isn't possible. --- [1] Sysadmin's rule of backups. If the data isn't backed up, by definition it is of less value than the resource and hassle cost of backup. No exceptions -- post-loss claims to the contrary simply put the lie to the claims, as actions spoke louder than words and they defined the cost of the backup as more expensive than the data that would have been backed up. Worst-case is then loss of data that was by definition of less value than the cost of backup, and the more valuable resource and hassle cost of the backup was avoided, so the comparatively lower value data loss is no big deal. So in a case like this, I'd simply power down and take my chances of filesystem loss, strictly limiting the time and resources I'd devote to any further attempt at recovery, because the data is by definition either backed up, or of such low value that a backup was considered too expensive to do, meaning there's a very real possibility of spending more time in a recovery attempt that's iffy at best, than the data on the filesystem is actually worth, either because there are backups, or because it's throw-away data in the first place. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- 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
System completely unresponsive after `btrfs balance start -dconvert=raid0 /` and `btrfs fi show /`
Hi all, I have an home server with 3 hard drives that I added to the same btrfs filesystem. Several hours ago I run `btrfs balance start -dconvert=raid0 /` and as soon as I run `btrfs fi show /` I lost my ssh connection to the machine. The machine is still on, but it doesn’t even respond to ping: I always get a request timeout and sometimes even an host is down message. Its fans are spinning at full blast and the hard drives’s led are registering activity all the time. I run Plex Home Theater too there and the display output is stuck at the time when I run those two commands. I left it running because I fear to lose everything by powering it down manually. Should I leave it like this and let it finish? How long it might take? (I have a 250gb internal hard drive, a 120gb usb 2.0 one and a 2TB usb 2.0 one so the transfer speeds are pretty low) Is it safe to power it off manually? Should I file a bug after it? Any help would be appreciated. Thanks, Carmine-- 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
Re: Upgrade to 3.14.0 messed up raid0 array (btrfs cleaner crashes in fs/btrfs/extent-tree.c:5748 and fs/btrfs/free-space-cache.c:1183 )
On Tue, Apr 08, 2014 at 10:31:39PM -0700, Marc MERLIN wrote: On Tue, Apr 08, 2014 at 09:31:25PM -0700, Marc MERLIN wrote: On Tue, Apr 08, 2014 at 07:49:14PM -0400, Chris Mason wrote: On 04/08/2014 06:09 PM, Marc MERLIN wrote: I forgot to add that while I'm not sure if anyone ended up looking at the last image I made regarding https://bugzilla.kernel.org/show_bug.cgi?id=72801 I can generate a an image of that filesystem if that helps, or try other commands which hopefully won't crash my running server :) (filesystem is almost 2TB, so the image will again be big) Hi Marc, So from the messages it looks like your space cache is corrupted. Lets start with clearing the space cache and running fsck and seeing exactly what is wrong. gargamel:~# mount -o clear_cache /dev/dm-4 /mnt/mnt [48132.661274] BTRFS: device label btrfs_raid0 devid 1 transid 50567 /dev/mapper/raid0d1 [48132.703063] BTRFS info (device dm-5): force clearing of disk cache [48132.724780] BTRFS info (device dm-5): disk space caching is enabled So, I tried again this morning, mounted with clear_cache, let the clearer process work a bit: root 25187 0.0 0.0 0 0 ?S07:56 0:00 [btrfs-freespace] but even though I did not have the FS mounted, after just one minute, the kernel went into that death loop again. Then (2nd log below), I tried mounting with -o clear_cache,nospace_cache and had the same problem too. I'll wait on your next suggestion, with maybe how you'd like me to run btrfsck Thanks, Marc [37652.548583] BTRFS: device label btrfs_raid0 devid 2 transid 50571 /dev/mapper/raid0d2 [37652.757397] BTRFS info (device dm-5): force clearing of disk cache [37652.779375] BTRFS info (device dm-5): disk space caching is enabled [37842.582194] WARNING: CPU: 2 PID: 25231 at fs/btrfs/extent-tree.c:5748 __btrfs_free_extent+0x359/0x712() [37842.613790] Modules linked in: udp_diag tcp_diag inet_diag ip6table_filter ip6_tables ebtable_nat ebtables tun ppdev lp autofs4 binfmt_misc kl5kusb105 deflate ctr twofish_avx_x86_64 twofish_x86_64_3way twofish_x86_64 twofish_generic twofish_common camellia_x86_64 camellia_generic serpent_sse2_x86_64 serpent_avx_x86_64 glue_helper lrw serpent_generic blowfish_x86_64 blowfish_generic blowfish_common cast5_avx_x86_64 ablk_helper cast5_generic cast_common des_generic cmac xcbc rmd160 sha512_ssse3 sha512_generic ftdi_sio crypto_null keyspan af_key xfrm_algo dm_mirror dm_region_hash dm_log nfsd nfs_acl auth_rpcgss nfs fscache lockd sunrpc ipt_REJECT xt_conntrack xt_nat xt_tcpudp xt_LOG iptable_mangle iptable_filter aes_x86_64 lm85 hwmon_vid dm_snapshot dm_bufio iptable_nat ip_tables nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_conntrack_ftp ipt_MASQUERADE nf_nat x_tables nf_conntrack sg st snd_pcm_oss snd_mixer_oss fuse microcode snd_hda_codec_realtek snd_cmipci snd_hda_codec_generic kvm_intel gameport kvm eeepc_wmi snd_hda_intel asus_wmi sparse_keymap snd_opl3_lib snd_mpu401_uart snd_seq_midi snd_hda_codec rfkill snd_seq_midi_event snd_seq snd_rawmidi snd_hwdep snd_pcm snd_timer tpm_infineon battery snd_seq_device wmi coretemp processor rc_ati_x10 pl2303 pcspkr snd intel_rapl asix tpm_tis x86_pkg_temp_thermal parport_pc ati_remote libphy ezusb soundcore i2c_i801 parport tpm intel_powerclamp rc_core lpc_ich xhci_hcd usbnet usbserial evdev xts gf128mul dm_crypt dm_mod raid456 async_raid6_recov async_pq async_xor async_memcpy async_tx e1000e ptp pps_core crc32_pclmul crc32c_intel ehci_pci sata_sil24 r8169 ehci_hcd thermal mii crct10dif_pclmul fan sata_mv ghash_clmulni_intel cryptd usbcore usb_common [last unloaded: kl5kusb105] [37843.113872] CPU: 2 PID: 25231 Comm: btrfs-cleaner Not tainted 3.14.0-amd64-i915-preempt-20140216 #2 [37843.143161] Hardware name: System manufacturer System Product Name/P8H67-M PRO, BIOS 3806 08/20/2012 [37843.143161] Hardware name: System manufacturer System Product Name/P8H67-M PRO, BIOS 3806 08/20/2012 [37843.172720] 880076d15b38 8160a06d [37843.197245] 880076d15b70 81050025 812170f6 8801bbdf3580 [37843.221785] fffe 000ee061 880076d15b80 [37843.246199] Call Trace: [37843.255694] [8160a06d] dump_stack+0x4e/0x7a [37843.273251] [81050025] warn_slowpath_common+0x7f/0x98 [37843.293448] [812170f6] ? __btrfs_free_extent+0x359/0x712 [37843.314212] [810500ec] warn_slowpath_null+0x1a/0x1c [37843.334376] [812170f6] __btrfs_free_extent+0x359/0x712 [37843.354692] [8160f97b] ? _raw_spin_unlock+0x17/0x2a [37843.374076] [8126518b] ? btrfs_check_delayed_seq+0x84/0x90 [37843.395273] [8121c262] __btrfs_run_delayed_refs+0xa94/0xbdf [37843.417102] [8113fcf3] ? __cache_free.isra.39+0x1b4/0x1c3 [37843.437969] [8121df46] btrfs_run_delayed_refs+0x81/0x18f [37843.458651]
Re: Upgrade to 3.14.0 messed up raid0 array (btrfs cleaner crashes in fs/btrfs/extent-tree.c:5748 and fs/btrfs/free-space-cache.c:1183 )
On 04/09/2014 11:42 AM, Marc MERLIN wrote: On Tue, Apr 08, 2014 at 10:31:39PM -0700, Marc MERLIN wrote: On Tue, Apr 08, 2014 at 09:31:25PM -0700, Marc MERLIN wrote: On Tue, Apr 08, 2014 at 07:49:14PM -0400, Chris Mason wrote: On 04/08/2014 06:09 PM, Marc MERLIN wrote: I forgot to add that while I'm not sure if anyone ended up looking at the last image I made regarding https://urldefense.proofpoint.com/v1/url?u=https://bugzilla.kernel.org/show_bug.cgi?id%3D72801k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0Ar=6%2FL0lzzDhu0Y1hL9xm%2BQyA%3D%3D%0Am=dQHW2ddzMXNlRthusH4o6nZVMltGycqZ8zO5AgwPphE%3D%0As=783fd1cd39566becdfb62904889cd7459c81dd2793d19538b2ab093bb8d06f88 I can generate a an image of that filesystem if that helps, or try other commands which hopefully won't crash my running server :) (filesystem is almost 2TB, so the image will again be big) Hi Marc, So from the messages it looks like your space cache is corrupted. Lets start with clearing the space cache and running fsck and seeing exactly what is wrong. gargamel:~# mount -o clear_cache /dev/dm-4 /mnt/mnt [48132.661274] BTRFS: device label btrfs_raid0 devid 1 transid 50567 /dev/mapper/raid0d1 [48132.703063] BTRFS info (device dm-5): force clearing of disk cache [48132.724780] BTRFS info (device dm-5): disk space caching is enabled So, I tried again this morning, mounted with clear_cache, let the clearer process work a bit: root 25187 0.0 0.0 0 0 ?S07:56 0:00 [btrfs-freespace] but even though I did not have the FS mounted, after just one minute, the kernel went into that death loop again. Then (2nd log below), I tried mounting with -o clear_cache,nospace_cache and had the same problem too. I'll wait on your next suggestion, with maybe how you'd like me to run btrfsck Downloading the image now. I'd just run a readonly btrfsck /dev/xxx -chris -- 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
Re: Upgrade to 3.14.0 messed up raid0 array (btrfs cleaner crashes in fs/btrfs/extent-tree.c:5748 and fs/btrfs/free-space-cache.c:1183 )
On Wed, Apr 09, 2014 at 11:46:13AM -0400, Chris Mason wrote: Downloading the image now. I'd just run a readonly btrfsck /dev/xxx http://marc.merlins.org/tmp/btrfs-raid0-image-fsck.txt (6MB) I admit to not knowing how to read that output, I've only ever seen thousands of lines of output from it on any filesystem., but hopefully you know how to grep out expected noise. But since we're talking about this, is btrfsck ever supposed to return clean on a clean filesystem? Thanks, Marc -- A mouse is a device used to point at the xterm you want to type in - A.S.R. Microsoft is to operating systems what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ -- 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
Re: Upgrade to 3.14.0 messed up raid0 array (btrfs cleaner crashes in fs/btrfs/extent-tree.c:5748 and fs/btrfs/free-space-cache.c:1183 )
On 04/09/2014 12:51 PM, Marc MERLIN wrote: On Wed, Apr 09, 2014 at 11:46:13AM -0400, Chris Mason wrote: Downloading the image now. I'd just run a readonly btrfsck /dev/xxx https://urldefense.proofpoint.com/v1/url?u=http://marc.merlins.org/tmp/btrfs-raid0-image-fsck.txtk=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0Ar=6%2FL0lzzDhu0Y1hL9xm%2BQyA%3D%3D%0Am=FvUwVb5mtQKfcHDJf0YzDhzyfAaFwrR9BXQbyCmT0No%3D%0As=633624e090ad2c187c1c5d62169bc0a8470ff2560049f83f195642638bff4b91 (6MB) I admit to not knowing how to read that output, I've only ever seen thousands of lines of output from it on any filesystem., but hopefully you know how to grep out expected noise. But since we're talking about this, is btrfsck ever supposed to return clean on a clean filesystem? Looks like I'm getting different results from btrfsck on the image. Still a ton of corruptions but complaints about different blocks. Can you please use btrfs-map-logical to dump both copies of block 245432320 and send me the results? -chris -- 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
Re: Upgrade to 3.14.0 messed up raid0 array (btrfs cleaner crashes in fs/btrfs/extent-tree.c:5748 and fs/btrfs/free-space-cache.c:1183 )
Marc MERLIN posted on Wed, 09 Apr 2014 09:51:34 -0700 as excerpted: But since we're talking about this, is btrfsck ever supposed to return clean on a clean filesystem? FWIW, it seems to return clean here, on everything I've tried it on. But I run relatively small partitions (the biggest is I believe 40 gig, my media partitions are still reiserfs on spinning rust, while all my btrfs partitions are on SSD and most are raid1 both data/metadata, with the exceptions (my normal /boot and the backup /boot on the other ssd in the pair that's btrfs raid1 for most partitions) being tiny mixed-data/ metadata dup), and keep them pretty clean, running balance and scrub when needed. I had seen some scrub recoveries back when I was doing suspend-to-ram and the system wasn't reliably resuming, I've quit doing that and recently did a new mkfs.btrfs and restored from backup on the affected filesystems in ordered to take advantage of newer features like 16k metadata nodes, so in fact have never personally seen an unclean output of any type from btrfs check. Tho I don't run btrfs check regularly as in normal mode it's read-only anyway, and I know it can make some problems worse instead of fixing them in repair mode, so my normal idea is why run it and see stuff that might make me worried if I can't really do much about it, and I prefer balance and scrub instead if there's problems. But I have run it a few times as I was curious just what it /would/ output, and everything came up clean on the filesystems I ran it on. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- 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
Upgrade to 3.14.0 messed up raid0 array (btrfs cleaner crashes in fs/btrfs/extent-tree.c:5748 and fs/btrfs/free-space-cache.c:1183 )
Soon after upgrading my server from 3.14rc5 to 3.14.0, my server went into a crash loop. Unfortunately because I used btrfs on my root filesystem, the problem didn't get logged because btrfs failing on a separate array prevented another thread to use btrfs to write on a healthy /var filesystem. So I found my system in a reboot loop, and after commenting out the devices in /etc/crypttab, prevented btrfs from mounting dm-5, which has restored my system to sanity for now, but with a missing filesystem. dm-5 was a 2 device raid0. I'm afraid of mounting it, because I think it'll crash my system again, but I'm happy to run commands against it. Question #1: Will mounting with read-only stop the cleaner process? Question #2: Is mounting with recovery,ro and copying the data out if I can the best way to recover? (and destroying, recreating the filesystem after that) Question #3: Any idea what happened and what bug I hit? Thanks, Marc Logs below: Will now mount local filesystems:[ 63.516591] EXT4-fs (md11): mounted filesystem with ordered data mode. Opts: (null) [ 63.540841] BTRFS: device label btrfs_boot devid 1 transid 130715 /dev/mapper/cryptroot [ 63.692581] BTRFS: device label btrfs_boot devid 1 transid 130715 /dev/mapper/cryptroot [ 63.836698] BTRFS: device label btrfs_boot devid 1 transid 130715 /dev/mapper/cryptroot [ 63.946790] BTRFS: device label btrfs_boot devid 1 transid 130715 /dev/mapper/cryptroot [ 64.119580] BTRFS: device label btrfs_raid0 devid 2 transid 50560 /dev/mapper/raid0d2 [ 64.145339] BTRFS info (device dm-5): disk space caching is enabled [ 71.139007] BTRFS: device label btrfs_boot devid 1 transid 130715 /dev/mapper/cryptroot [ 71.337153] BTRFS: device label btrfs_raid0 devid 2 transid 50560 /dev/mapper/raid0d2 [ 71.395269] BTRFS: device label btrfs_pool1 devid 1 transid 43963 /dev/mapper/dshelf1 [ 71.420616] BTRFS info (device dm-1): disk space caching is enabled [ 96.523664] BTRFS: device label btrfs_pool2 devid 1 transid 42458 /dev/mapper/dshelf2 [ 96.549209] BTRFS info (device dm-2): disk space caching is enabled [ 96.568833] BTRFS: has skinny extents [ 102.679436] [ cut here ] [ 102.694202] WARNING: CPU: 2 PID: 3105 at fs/btrfs/extent-tree.c:5748 __btrfs_free_extent+0x359/0x712() [ 102.723152] Modules linked in: aes_x86_64 lm85 hwmon_vid dm_snapshot dm_bufio iptable_nat ip_tables nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_conntrack_ftp ipt_MASQUERADE nf_nat x_tables nf_conntrack sg st snd_pcm_oss snd_mixer_oss fuse snd_hda_codec_realtek microcode snd_hda_codec_generic snd_cmipci kvm_intel gameport kvm snd_hda_intel snd_hda_codec snd_opl3_lib eeepc_wmi snd_mpu401_uart snd_seq_midi snd_seq_midi_event snd_seq asus_wmi tpm_infineon snd_hwdep sparse_keymap snd_pcm snd_rawmidi coretemp rfkill battery snd_timer snd_seq_device intel_rapl rc_ati_x10 snd tpm_tis ati_remote processor x86_pkg_temp_thermal wmi tpm asix pl2303 lpc_ich i2c_i801 soundcore libphy parport_pc intel_powerclamp ftdi_sio keyspan parport usbnet pcspkr evdev rc_core xhci_hcd usbserial ezusb xts gf128mul dm_crypt dm_mod raid456 async_raid6_recov async_pq async_xor async_memcpy async_tx e1000e ptp pps_core crc32_pclmul crc32c_intel ehci_pci ehci_hcd crct10dif_pclmul sata_sil24 usbcore ghash_clmulni_intel cryptd fan thermal r8169 mii usb_common sata_mv [ 103.011058] CPU: 2 PID: 3105 Comm: btrfs-cleaner Not tainted 3.14.0-amd64-i915-preempt-20140216 #2 [ 103.038925] Hardware name: System manufacturer System Product Name/P8H67-M PRO, BIOS 3806 08/20/2012 [ 103.067351] 880213f63b38 8160a06d [ 103.090778] 880213f63b70 81050025 812170f6 880211a58f10 [ 103.114210] fffe 000ee05cc000 880213f63b80 [ 103.137678] Call Trace: [ 103.146122] [8160a06d] dump_stack+0x4e/0x7a [ 103.162653] [81050025] warn_slowpath_common+0x7f/0x98 [ 103.181877] [812170f6] ? __btrfs_free_extent+0x359/0x712 [ 103.201778] [810500ec] warn_slowpath_null+0x1a/0x1c [ 103.220393] [812170f6] __btrfs_free_extent+0x359/0x712 [ 103.239793] [8160f97b] ? _raw_spin_unlock+0x17/0x2a [ 103.258428] [8126518b] ? btrfs_check_delayed_seq+0x84/0x90 [ 103.278897] [8121c262] __btrfs_run_delayed_refs+0xa94/0xbdf [ 103.299623] [8113fcf3] ? __cache_free.isra.39+0x1b4/0x1c3 [ 103.319852] [8121df46] btrfs_run_delayed_refs+0x81/0x18f [ 103.339823] [8121ac3a] ? walk_up_tree+0x72/0xf9 [ 103.357452] [8122af08] btrfs_should_end_transaction+0x52/0x5b [ 103.378698] [8121cba9] btrfs_drop_snapshot+0x36f/0x610 [ 103.398131] [8122c73d] btrfs_clean_one_deleted_snapshot+0x103/0x10f [ 103.420997] [81224f09] cleaner_kthread+0x103/0x136 [ 103.439399] [81224e06] ? btrfs_alloc_root+0x26/0x26 [ 103.458068] [8106bc62]
Re: Upgrade to 3.14.0 messed up raid0 array (btrfs cleaner crashes in fs/btrfs/extent-tree.c:5748 and fs/btrfs/free-space-cache.c:1183 )
I forgot to add that while I'm not sure if anyone ended up looking at the last image I made regarding https://bugzilla.kernel.org/show_bug.cgi?id=72801 I can generate a an image of that filesystem if that helps, or try other commands which hopefully won't crash my running server :) (filesystem is almost 2TB, so the image will again be big) Marc On Tue, Apr 08, 2014 at 08:36:09AM -0700, Marc MERLIN wrote: Soon after upgrading my server from 3.14rc5 to 3.14.0, my server went into a crash loop. Unfortunately because I used btrfs on my root filesystem, the problem didn't get logged because btrfs failing on a separate array prevented another thread to use btrfs to write on a healthy /var filesystem. So I found my system in a reboot loop, and after commenting out the devices in /etc/crypttab, prevented btrfs from mounting dm-5, which has restored my system to sanity for now, but with a missing filesystem. dm-5 was a 2 device raid0. I'm afraid of mounting it, because I think it'll crash my system again, but I'm happy to run commands against it. Question #1: Will mounting with read-only stop the cleaner process? Question #2: Is mounting with recovery,ro and copying the data out if I can the best way to recover? (and destroying, recreating the filesystem after that) Question #3: Any idea what happened and what bug I hit? Thanks, Marc Logs below: Will now mount local filesystems:[ 63.516591] EXT4-fs (md11): mounted filesystem with ordered data mode. Opts: (null) [ 63.540841] BTRFS: device label btrfs_boot devid 1 transid 130715 /dev/mapper/cryptroot [ 63.692581] BTRFS: device label btrfs_boot devid 1 transid 130715 /dev/mapper/cryptroot [ 63.836698] BTRFS: device label btrfs_boot devid 1 transid 130715 /dev/mapper/cryptroot [ 63.946790] BTRFS: device label btrfs_boot devid 1 transid 130715 /dev/mapper/cryptroot [ 64.119580] BTRFS: device label btrfs_raid0 devid 2 transid 50560 /dev/mapper/raid0d2 [ 64.145339] BTRFS info (device dm-5): disk space caching is enabled [ 71.139007] BTRFS: device label btrfs_boot devid 1 transid 130715 /dev/mapper/cryptroot [ 71.337153] BTRFS: device label btrfs_raid0 devid 2 transid 50560 /dev/mapper/raid0d2 [ 71.395269] BTRFS: device label btrfs_pool1 devid 1 transid 43963 /dev/mapper/dshelf1 [ 71.420616] BTRFS info (device dm-1): disk space caching is enabled [ 96.523664] BTRFS: device label btrfs_pool2 devid 1 transid 42458 /dev/mapper/dshelf2 [ 96.549209] BTRFS info (device dm-2): disk space caching is enabled [ 96.568833] BTRFS: has skinny extents [ 102.679436] [ cut here ] [ 102.694202] WARNING: CPU: 2 PID: 3105 at fs/btrfs/extent-tree.c:5748 __btrfs_free_extent+0x359/0x712() [ 102.723152] Modules linked in: aes_x86_64 lm85 hwmon_vid dm_snapshot dm_bufio iptable_nat ip_tables nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_conntrack_ftp ipt_MASQUERADE nf_nat x_tables nf_conntrack sg st snd_pcm_oss snd_mixer_oss fuse snd_hda_codec_realtek microcode snd_hda_codec_generic snd_cmipci kvm_intel gameport kvm snd_hda_intel snd_hda_codec snd_opl3_lib eeepc_wmi snd_mpu401_uart snd_seq_midi snd_seq_midi_event snd_seq asus_wmi tpm_infineon snd_hwdep sparse_keymap snd_pcm snd_rawmidi coretemp rfkill battery snd_timer snd_seq_device intel_rapl rc_ati_x10 snd tpm_tis ati_remote processor x86_pkg_temp_thermal wmi tpm asix pl2303 lpc_ich i2c_i801 soundcore libphy parport_pc intel_powerclamp ftdi_sio keyspan parport usbnet pcspkr evdev rc_core xhci_hcd usbserial ezusb xts gf128mul dm_crypt dm_mod raid456 async_raid6_recov async_pq async_xor async_memcpy async_tx e1000e ptp pps_core crc32_pclmul crc32c_intel ehci_pci ehci_hcd crct10dif_pclmul sata_sil24 usbcore ghash_clmulni_intel cryptd fan thermal r8169 mii usb_common sata_mv [ 103.011058] CPU: 2 PID: 3105 Comm: btrfs-cleaner Not tainted 3.14.0-amd64-i915-preempt-20140216 #2 [ 103.038925] Hardware name: System manufacturer System Product Name/P8H67-M PRO, BIOS 3806 08/20/2012 [ 103.067351] 880213f63b38 8160a06d [ 103.090778] 880213f63b70 81050025 812170f6 880211a58f10 [ 103.114210] fffe 000ee05cc000 880213f63b80 [ 103.137678] Call Trace: [ 103.146122] [8160a06d] dump_stack+0x4e/0x7a [ 103.162653] [81050025] warn_slowpath_common+0x7f/0x98 [ 103.181877] [812170f6] ? __btrfs_free_extent+0x359/0x712 [ 103.201778] [810500ec] warn_slowpath_null+0x1a/0x1c [ 103.220393] [812170f6] __btrfs_free_extent+0x359/0x712 [ 103.239793] [8160f97b] ? _raw_spin_unlock+0x17/0x2a [ 103.258428] [8126518b] ? btrfs_check_delayed_seq+0x84/0x90 [ 103.278897] [8121c262] __btrfs_run_delayed_refs+0xa94/0xbdf [ 103.299623] [8113fcf3] ? __cache_free.isra.39+0x1b4/0x1c3 [ 103.319852]
Re: Upgrade to 3.14.0 messed up raid0 array (btrfs cleaner crashes in fs/btrfs/extent-tree.c:5748 and fs/btrfs/free-space-cache.c:1183 )
On 04/08/2014 06:09 PM, Marc MERLIN wrote: I forgot to add that while I'm not sure if anyone ended up looking at the last image I made regarding https://bugzilla.kernel.org/show_bug.cgi?id=72801 I can generate a an image of that filesystem if that helps, or try other commands which hopefully won't crash my running server :) (filesystem is almost 2TB, so the image will again be big) Hi Marc, So from the messages it looks like your space cache is corrupted. Lets start with clearing the space cache and running fsck and seeing exactly what is wrong. An image will definitely help if you have a pipe big enough to upload it. -chris -- 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
Re: Upgrade to 3.14.0 messed up raid0 array (btrfs cleaner crashes in fs/btrfs/extent-tree.c:5748 and fs/btrfs/free-space-cache.c:1183 )
On Tue, Apr 08, 2014 at 07:49:14PM -0400, Chris Mason wrote: On 04/08/2014 06:09 PM, Marc MERLIN wrote: I forgot to add that while I'm not sure if anyone ended up looking at the last image I made regarding https://bugzilla.kernel.org/show_bug.cgi?id=72801 I can generate a an image of that filesystem if that helps, or try other commands which hopefully won't crash my running server :) (filesystem is almost 2TB, so the image will again be big) Hi Marc, So from the messages it looks like your space cache is corrupted. Lets start with clearing the space cache and running fsck and seeing exactly what is wrong. gargamel:~# mount -o clear_cache /dev/dm-4 /mnt/mnt [48132.661274] BTRFS: device label btrfs_raid0 devid 1 transid 50567 /dev/mapper/raid0d1 [48132.703063] BTRFS info (device dm-5): force clearing of disk cache [48132.724780] BTRFS info (device dm-5): disk space caching is enabled Mmmh, I've never had much luck with btrfsck An image will definitely help if you have a pipe big enough to upload it. Mmmh, I guess I should have taken this before the clear_cache mount, but even after that, I still got the crash, so let me take an image first Then, what fsck options do you recommend? Thanks, Marc -- A mouse is a device used to point at the xterm you want to type in - A.S.R. Microsoft is to operating systems what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ -- 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
Re: Upgrade to 3.14.0 messed up raid0 array (btrfs cleaner crashes in fs/btrfs/extent-tree.c:5748 and fs/btrfs/free-space-cache.c:1183 )
On Tue, Apr 08, 2014 at 09:31:25PM -0700, Marc MERLIN wrote: On Tue, Apr 08, 2014 at 07:49:14PM -0400, Chris Mason wrote: On 04/08/2014 06:09 PM, Marc MERLIN wrote: I forgot to add that while I'm not sure if anyone ended up looking at the last image I made regarding https://bugzilla.kernel.org/show_bug.cgi?id=72801 I can generate a an image of that filesystem if that helps, or try other commands which hopefully won't crash my running server :) (filesystem is almost 2TB, so the image will again be big) Hi Marc, So from the messages it looks like your space cache is corrupted. Lets start with clearing the space cache and running fsck and seeing exactly what is wrong. gargamel:~# mount -o clear_cache /dev/dm-4 /mnt/mnt [48132.661274] BTRFS: device label btrfs_raid0 devid 1 transid 50567 /dev/mapper/raid0d1 [48132.703063] BTRFS info (device dm-5): force clearing of disk cache [48132.724780] BTRFS info (device dm-5): disk space caching is enabled Mmmh, I've never had much luck with btrfsck An image will definitely help if you have a pipe big enough to upload it. Mmmh, I guess I should have taken this before the clear_cache mount, but even after that, I still got the crash, so let me take an image first Then, what fsck options do you recommend? Here is the image (1.5GB): http://marc.merlins.org/tmp/btrfs-raid0-image Please let me know when I can remove it. It was taken right after I tried a mount again, and soon after got: [48297.721718] BTRFS: device label btrfs_raid0 devid 2 transid 50567 /dev/mapper/raid0d2 [48317.369527] [ cut here ] [48317.385559] WARNING: CPU: 3 PID: 13019 at fs/btrfs/extent-tree.c:5748 __btrfs_free_extent+0x359/0x712() [48317.415941] Modules linked in: ip6table_filter ip6_tables ebtable_nat ebtables tun ppdev lp autofs4 binfmt_misc kl5kusb105 deflate ctr twofish_avx_x86_64 twofish_x86_64_3way twofish_x86_64 twofish_generic twofish_common camellia_x86_64 camellia_generic serpent_sse2_x86_64 serpent_avx_x86_64 glue_helper lrw serpent_generic blowfish_x86_64 blowfish_generic blowfish_common cast5_avx_x86_64 ablk_helper cast5_generic cast_common des_generic cmac xcbc rmd160 sha512_ssse3 sha512_generic ftdi_sio crypto_null keyspan af_key xfrm_algo dm_mirror dm_region_hash dm_log nfsd nfs_acl auth_rpcgss nfs fscache lockd sunrpc ipt_REJECT xt_conntrack xt_nat xt_tcpudp xt_LOG iptable_mangle iptable_filter aes_x86_64 lm85 hwmon_vid dm_snapshot dm_bufio iptable_nat ip_tables nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_conntrack_ftp ipt_MASQUERADE nf_nat x_tables nf_conntrack sg st snd_pcm_oss snd_mixer_oss fuse eeepc_wmi microcode asus_wmi kvm_intel sparse_keymap snd_hda_codec_realtek rfkill snd_hda_codec_generic kvm snd_cmipci gameport snd_hda_intel snd_opl3_lib snd_mpu401_uart snd_seq_midi snd_hda_codec snd_seq_midi_event snd_seq snd_rawmidi snd_hwdep asix snd_pcm snd_timer battery tpm_infineon snd_seq_device coretemp libphy processor wmi pl2303 pcspkr snd parport_pc intel_rapl i2c_i801 usbnet rc_ati_x10 parport lpc_ich xhci_hcd tpm_tis ati_remote x86_pkg_temp_thermal intel_powerclamp evdev tpm rc_core soundcore usbserial ezusb xts gf128mul dm_crypt dm_mod raid456 async_raid6_recov async_pq async_xor async_memcpy async_tx e1000e ptp pps_core ehci_pci ehci_hcd crc32_pclmul crc32c_intel sata_sil24 crct10dif_pclmul ghash_clmulni_intel thermal cryptd fan r8169 mii usbcore usb_common sata_mv [last unloaded: kl5kusb105] [48317.913132] CPU: 3 PID: 13019 Comm: btrfs-cleaner Not tainted 3.14.0-amd64-i915-preempt-20140216 #2 [48317.943303] Hardware name: System manufacturer System Product Name/P8H67-M PRO, BIOS 3806 08/20/2012 [48317.973797] 8801bbfd5b38 8160a06d [48317.998522] 8801bbfd5b70 81050025 812170f6 880211af3970 [48318.022993] fffe 000ee05cc000 8801bbfd5b80 [48318.047511] Call Trace: [48318.057221] [8160a06d] dump_stack+0x4e/0x7a [48318.074556] [81050025] warn_slowpath_common+0x7f/0x98 [48318.095323] [812170f6] ? __btrfs_free_extent+0x359/0x712 [48318.116854] [810500ec] warn_slowpath_null+0x1a/0x1c [48318.136119] [812170f6] __btrfs_free_extent+0x359/0x712 [48318.156327] [8160f97b] ? _raw_spin_unlock+0x17/0x2a [48318.175732] [8126518b] ? btrfs_check_delayed_seq+0x84/0x90 [48318.196996] [8121c262] __btrfs_run_delayed_refs+0xa94/0xbdf [48318.218542] [8113fcf3] ? __cache_free.isra.39+0x1b4/0x1c3 [48318.239536] [8121df46] btrfs_run_delayed_refs+0x81/0x18f [48318.260623] [8121ac3a] ? walk_up_tree+0x72/0xf9 [48318.279115] [8122af08] btrfs_should_end_transaction+0x52/0x5b [48318.301178] [8121cba9] btrfs_drop_snapshot+0x36f/0x610 [48318.321381] [8122c73d] btrfs_clean_one_deleted_snapshot+0x103/0x10f [48318.344943] [81224f09
Re: Raid0 with btrfs
On Sat, Aug 7, 2010 at 1:03 AM, Sebastian 'gonX' Jensen g...@overclocked.net wrote: On 7 August 2010 00:24, Leonidas Spyropoulos artafi...@gmail.com wrote: On Fri, Aug 6, 2010 at 7:32 PM, Sebastian 'gonX' Jensen g...@overclocked.net wrote: On 6 August 2010 20:23, Leonidas Spyropoulos artafi...@gmail.com wrote: Do I have to change the partition ID flag of each partition? Currently is set to fd (Linux Raid autodetect) for used from mdadm mkfs.btrfs supports that or needs to be 83 (Linux) ? FD is for mdraid integrated into the Linux kernel. I have mine at 83. It won't hurt to have them at FD, but the kernel will spend extra time as it probes the devices on boot, causing a slight slowdown. Ok done them id 83 and used 3 devices eventually Using raid0 for data and metadata # mkfs.btrfs -m raid0 -d raid0 /dev/sdc1 /dev/sdd2 /dev/sde2 2 SATA and 1 ATA drive I thought that ATA will bottleneck the other 2 drives but seems like I gain something from it. Using iozone for benchmark: # iozone -s 8g -r 1024 -i 0 -i 1 with 2 SATA devices and then 3 devices (SATA + ATA): KB reclen write rewrite read reread 8388608 1024 134869 139607 229146 228800 8388608 1024 135151 139050 233461 235929 The above is with -o compress option enabled and my cpu topped up on 100% cpu (both cores) while test and copy huge data. Is it possible I am bottlenecked by my cpu speed? AMD Opteron 165 @ 2700 Mhz On Thu, Aug 5, 2010 at 3:40 PM, Hubert Kario h...@qbs.com.pl wrote: On Thursday 05 August 2010 16:15:22 Leonidas Spyropoulos wrote: Hi all, I want to make a btrfs raid0 on 2 partitions of my pc. Until now I am using the mdadm tools to make a software raid of the 2 partitions /dev/sde2, /dev/sdd2 and then mkfs.etx4 the newly created /dev/md0 device. From performance point of view is it better to keep the configuration of mdadm and just format the /dev/md0 device as btrfs OR delete the raid device and format the 2 partitions /dev/sde2 /dev/sdd2 as a btrfs with 2 devices? mkfs.btrfs /dev/sde2 /dev/sdd2 Btrfs already supports metadata mirroring when the data is striped. What this means, is while the performance should be more-or-less identical to MD RAID0 (if it isn't it's a bug), your data is a bit more secure as the metadata describing it resides on both drives. Later on it will be possible to selct which directories/files should have what level of redundancy. This will allow to have ~/work RAID1-ed and ~/videos RAID0-ed while keeping both directories on the same partition and filesystem. On a sidenote: If I decide to go for raid5 which is not supported currently from mkfs I have to use the mdadm tool anyway, right? yes, RAID5 code is not in trunk yet. -- 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 -- Caution: breathing may be hazardous to your health. -- 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 Regards, Sebastian J. PS. Please try to bottom-post rather than top-post. Here's a link I can advise reading for a clarification on why bottom posting is essential: http://www.caliburn.nl/topposting.html Thanks for the heads up about bottom-posting. -- Caution: breathing may be hazardous to your health. It seems odd that you are reaching 100% CPU usage. Maybe it's because I am on an Intel processor with the integrated crc32c module, but with metadata and data striping on 2 decent desktop drives (60 MB/s in avg each on large reads), I don't go much anywhere near 10% CPU usage, and I have compress-force enabled. I've never tried a stress test iozone, but if I can still remember it, I will try to run it once I get back from holidays. Sorry that it doesn't help your problem, but it seems like it's something else. I really doubt my old Opteron has SSE 4.2 and as mentioned from other users it makes a huge difference. I'm assuming you're running the nForce4 chipset. I don't recall it being there, but is there an AHCI option for S-ATA in the BIOS, rather than legacy or PATA mode, or something in the lines of that? That could in theory reduce CPU usage somewhat, but shouldn't really affect anything before very high transfer speeds. Yes it's an nForce4 chipset (DFI Expert) And if I recall it's SATA+PATA mode enabled on mine now. I can't be sure since I am working on it from ssh. And yes, you are bottlenecked if you're running at max CPU usage. I would try disabling the compress mount option if the above does not help. After disabling the compress and done the test again it affected the write speed and my CPU wasn't topped up all the time something like 80-90% results with iozone KB reclen write rewrite read reread 83886081024 147736 147062
Re: Raid0 with btrfs
On Sat, Aug 7, 2010 at 12:16 PM, Leonidas Spyropoulos artafi...@gmail.com wrote: On Sat, Aug 7, 2010 at 1:03 AM, Sebastian 'gonX' Jensen g...@overclocked.net wrote: On 7 August 2010 00:24, Leonidas Spyropoulos artafi...@gmail.com wrote: On Fri, Aug 6, 2010 at 7:32 PM, Sebastian 'gonX' Jensen g...@overclocked.net wrote: On 6 August 2010 20:23, Leonidas Spyropoulos artafi...@gmail.com wrote: Do I have to change the partition ID flag of each partition? Currently is set to fd (Linux Raid autodetect) for used from mdadm mkfs.btrfs supports that or needs to be 83 (Linux) ? FD is for mdraid integrated into the Linux kernel. I have mine at 83. It won't hurt to have them at FD, but the kernel will spend extra time as it probes the devices on boot, causing a slight slowdown. Ok done them id 83 and used 3 devices eventually Using raid0 for data and metadata # mkfs.btrfs -m raid0 -d raid0 /dev/sdc1 /dev/sdd2 /dev/sde2 2 SATA and 1 ATA drive I thought that ATA will bottleneck the other 2 drives but seems like I gain something from it. Using iozone for benchmark: # iozone -s 8g -r 1024 -i 0 -i 1 with 2 SATA devices and then 3 devices (SATA + ATA): KB reclen write rewrite read reread 8388608 1024 134869 139607 229146 228800 8388608 1024 135151 139050 233461 235929 The above is with -o compress option enabled and my cpu topped up on 100% cpu (both cores) while test and copy huge data. Is it possible I am bottlenecked by my cpu speed? AMD Opteron 165 @ 2700 Mhz On Thu, Aug 5, 2010 at 3:40 PM, Hubert Kario h...@qbs.com.pl wrote: On Thursday 05 August 2010 16:15:22 Leonidas Spyropoulos wrote: Hi all, I want to make a btrfs raid0 on 2 partitions of my pc. Until now I am using the mdadm tools to make a software raid of the 2 partitions /dev/sde2, /dev/sdd2 and then mkfs.etx4 the newly created /dev/md0 device. From performance point of view is it better to keep the configuration of mdadm and just format the /dev/md0 device as btrfs OR delete the raid device and format the 2 partitions /dev/sde2 /dev/sdd2 as a btrfs with 2 devices? mkfs.btrfs /dev/sde2 /dev/sdd2 Btrfs already supports metadata mirroring when the data is striped. What this means, is while the performance should be more-or-less identical to MD RAID0 (if it isn't it's a bug), your data is a bit more secure as the metadata describing it resides on both drives. Later on it will be possible to selct which directories/files should have what level of redundancy. This will allow to have ~/work RAID1-ed and ~/videos RAID0-ed while keeping both directories on the same partition and filesystem. On a sidenote: If I decide to go for raid5 which is not supported currently from mkfs I have to use the mdadm tool anyway, right? yes, RAID5 code is not in trunk yet. -- 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 -- Caution: breathing may be hazardous to your health. -- 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 Regards, Sebastian J. PS. Please try to bottom-post rather than top-post. Here's a link I can advise reading for a clarification on why bottom posting is essential: http://www.caliburn.nl/topposting.html Thanks for the heads up about bottom-posting. -- Caution: breathing may be hazardous to your health. It seems odd that you are reaching 100% CPU usage. Maybe it's because I am on an Intel processor with the integrated crc32c module, but with metadata and data striping on 2 decent desktop drives (60 MB/s in avg each on large reads), I don't go much anywhere near 10% CPU usage, and I have compress-force enabled. I've never tried a stress test iozone, but if I can still remember it, I will try to run it once I get back from holidays. Sorry that it doesn't help your problem, but it seems like it's something else. I really doubt my old Opteron has SSE 4.2 and as mentioned from other users it makes a huge difference. I'm assuming you're running the nForce4 chipset. I don't recall it being there, but is there an AHCI option for S-ATA in the BIOS, rather than legacy or PATA mode, or something in the lines of that? That could in theory reduce CPU usage somewhat, but shouldn't really affect anything before very high transfer speeds. Yes it's an nForce4 chipset (DFI Expert) And if I recall it's SATA+PATA mode enabled on mine now. I can't be sure since I am working on it from ssh. And yes, you are bottlenecked if you're running at max CPU usage. I would try disabling the compress mount option if the above does not help. After disabling the compress and done the test again it affected the write speed and my CPU wasn't topped up all the time something like 80-90% results with iozone
Re: Raid0 with btrfs
On 6 August 2010 20:23, Leonidas Spyropoulos artafi...@gmail.com wrote: Do I have to change the partition ID flag of each partition? Currently is set to fd (Linux Raid autodetect) for used from mdadm mkfs.btrfs supports that or needs to be 83 (Linux) ? FD is for mdraid integrated into the Linux kernel. I have mine at 83. It won't hurt to have them at FD, but the kernel will spend extra time as it probes the devices on boot, causing a slight slowdown. On Thu, Aug 5, 2010 at 3:40 PM, Hubert Kario h...@qbs.com.pl wrote: On Thursday 05 August 2010 16:15:22 Leonidas Spyropoulos wrote: Hi all, I want to make a btrfs raid0 on 2 partitions of my pc. Until now I am using the mdadm tools to make a software raid of the 2 partitions /dev/sde2, /dev/sdd2 and then mkfs.etx4 the newly created /dev/md0 device. From performance point of view is it better to keep the configuration of mdadm and just format the /dev/md0 device as btrfs OR delete the raid device and format the 2 partitions /dev/sde2 /dev/sdd2 as a btrfs with 2 devices? mkfs.btrfs /dev/sde2 /dev/sdd2 Btrfs already supports metadata mirroring when the data is striped. What this means, is while the performance should be more-or-less identical to MD RAID0 (if it isn't it's a bug), your data is a bit more secure as the metadata describing it resides on both drives. Later on it will be possible to selct which directories/files should have what level of redundancy. This will allow to have ~/work RAID1-ed and ~/videos RAID0-ed while keeping both directories on the same partition and filesystem. On a sidenote: If I decide to go for raid5 which is not supported currently from mkfs I have to use the mdadm tool anyway, right? yes, RAID5 code is not in trunk yet. -- 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 -- Caution: breathing may be hazardous to your health. -- 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 Regards, Sebastian J. PS. Please try to bottom-post rather than top-post. Here's a link I can advise reading for a clarification on why bottom posting is essential: http://www.caliburn.nl/topposting.html -- 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
Re: Raid0 with btrfs
On Saturday 07 of August 2010 00:24:08 Leonidas Spyropoulos wrote: On Fri, Aug 6, 2010 at 7:32 PM, Sebastian 'gonX' Jensen g...@overclocked.net wrote: On 6 August 2010 20:23, Leonidas Spyropoulos artafi...@gmail.com wrote: Do I have to change the partition ID flag of each partition? Currently is set to fd (Linux Raid autodetect) for used from mdadm mkfs.btrfs supports that or needs to be 83 (Linux) ? FD is for mdraid integrated into the Linux kernel. I have mine at 83. It won't hurt to have them at FD, but the kernel will spend extra time as it probes the devices on boot, causing a slight slowdown. Ok done them id 83 and used 3 devices eventually Using raid0 for data and metadata # mkfs.btrfs -m raid0 -d raid0 /dev/sdc1 /dev/sdd2 /dev/sde2 2 SATA and 1 ATA drive I thought that ATA will bottleneck the other 2 drives but seems like I gain something from it. Using iozone for benchmark: # iozone -s 8g -r 1024 -i 0 -i 1 with 2 SATA devices and then 3 devices (SATA + ATA): KB reclen write rewrite read reread 83886081024 134869 139607 229146 228800 83886081024 135151 139050 233461 235929 The above is with -o compress option enabled and my cpu topped up on 100% cpu (both cores) while test and copy huge data. Is it possible I am bottlenecked by my cpu speed? AMD Opteron 165 @ 2700 Mhz Considering you have 100% CPU usage during the test, it would seem so. On Thu, Aug 5, 2010 at 3:40 PM, Hubert Kario h...@qbs.com.pl wrote: On Thursday 05 August 2010 16:15:22 Leonidas Spyropoulos wrote: Hi all, I want to make a btrfs raid0 on 2 partitions of my pc. Until now I am using the mdadm tools to make a software raid of the 2 partitions /dev/sde2, /dev/sdd2 and then mkfs.etx4 the newly created /dev/md0 device. From performance point of view is it better to keep the configuration of mdadm and just format the /dev/md0 device as btrfs OR delete the raid device and format the 2 partitions /dev/sde2 /dev/sdd2 as a btrfs with 2 devices? mkfs.btrfs /dev/sde2 /dev/sdd2 Btrfs already supports metadata mirroring when the data is striped. What this means, is while the performance should be more-or-less identical to MD RAID0 (if it isn't it's a bug), your data is a bit more secure as the metadata describing it resides on both drives. Later on it will be possible to selct which directories/files should have what level of redundancy. This will allow to have ~/work RAID1-ed and ~/videos RAID0-ed while keeping both directories on the same partition and filesystem. On a sidenote: If I decide to go for raid5 which is not supported currently from mkfs I have to use the mdadm tool anyway, right? yes, RAID5 code is not in trunk yet. -- 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 -- Caution: breathing may be hazardous to your health. -- 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 Regards, Sebastian J. PS. Please try to bottom-post rather than top-post. Here's a link I can advise reading for a clarification on why bottom posting is essential: http://www.caliburn.nl/topposting.html Thanks for the heads up about bottom-posting. -- 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
Re: Raid0 with btrfs
On 7 August 2010 00:24, Leonidas Spyropoulos artafi...@gmail.com wrote: On Fri, Aug 6, 2010 at 7:32 PM, Sebastian 'gonX' Jensen g...@overclocked.net wrote: On 6 August 2010 20:23, Leonidas Spyropoulos artafi...@gmail.com wrote: Do I have to change the partition ID flag of each partition? Currently is set to fd (Linux Raid autodetect) for used from mdadm mkfs.btrfs supports that or needs to be 83 (Linux) ? FD is for mdraid integrated into the Linux kernel. I have mine at 83. It won't hurt to have them at FD, but the kernel will spend extra time as it probes the devices on boot, causing a slight slowdown. Ok done them id 83 and used 3 devices eventually Using raid0 for data and metadata # mkfs.btrfs -m raid0 -d raid0 /dev/sdc1 /dev/sdd2 /dev/sde2 2 SATA and 1 ATA drive I thought that ATA will bottleneck the other 2 drives but seems like I gain something from it. Using iozone for benchmark: # iozone -s 8g -r 1024 -i 0 -i 1 with 2 SATA devices and then 3 devices (SATA + ATA): KB reclen write rewrite read reread 8388608 1024 134869 139607 229146 228800 8388608 1024 135151 139050 233461 235929 The above is with -o compress option enabled and my cpu topped up on 100% cpu (both cores) while test and copy huge data. Is it possible I am bottlenecked by my cpu speed? AMD Opteron 165 @ 2700 Mhz On Thu, Aug 5, 2010 at 3:40 PM, Hubert Kario h...@qbs.com.pl wrote: On Thursday 05 August 2010 16:15:22 Leonidas Spyropoulos wrote: Hi all, I want to make a btrfs raid0 on 2 partitions of my pc. Until now I am using the mdadm tools to make a software raid of the 2 partitions /dev/sde2, /dev/sdd2 and then mkfs.etx4 the newly created /dev/md0 device. From performance point of view is it better to keep the configuration of mdadm and just format the /dev/md0 device as btrfs OR delete the raid device and format the 2 partitions /dev/sde2 /dev/sdd2 as a btrfs with 2 devices? mkfs.btrfs /dev/sde2 /dev/sdd2 Btrfs already supports metadata mirroring when the data is striped. What this means, is while the performance should be more-or-less identical to MD RAID0 (if it isn't it's a bug), your data is a bit more secure as the metadata describing it resides on both drives. Later on it will be possible to selct which directories/files should have what level of redundancy. This will allow to have ~/work RAID1-ed and ~/videos RAID0-ed while keeping both directories on the same partition and filesystem. On a sidenote: If I decide to go for raid5 which is not supported currently from mkfs I have to use the mdadm tool anyway, right? yes, RAID5 code is not in trunk yet. -- 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 -- Caution: breathing may be hazardous to your health. -- 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 Regards, Sebastian J. PS. Please try to bottom-post rather than top-post. Here's a link I can advise reading for a clarification on why bottom posting is essential: http://www.caliburn.nl/topposting.html Thanks for the heads up about bottom-posting. -- Caution: breathing may be hazardous to your health. It seems odd that you are reaching 100% CPU usage. Maybe it's because I am on an Intel processor with the integrated crc32c module, but with metadata and data striping on 2 decent desktop drives (60 MB/s in avg each on large reads), I don't go much anywhere near 10% CPU usage, and I have compress-force enabled. I've never tried a stress test iozone, but if I can still remember it, I will try to run it once I get back from holidays. Sorry that it doesn't help your problem, but it seems like it's something else. I'm assuming you're running the nForce4 chipset. I don't recall it being there, but is there an AHCI option for S-ATA in the BIOS, rather than legacy or PATA mode, or something in the lines of that? That could in theory reduce CPU usage somewhat, but shouldn't really affect anything before very high transfer speeds. And yes, you are bottlenecked if you're running at max CPU usage. I would try disabling the compress mount option if the above does not help. Regards, Sebastian J. -- 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
Raid0 with btrfs
Hi all, I want to make a btrfs raid0 on 2 partitions of my pc. Until now I am using the mdadm tools to make a software raid of the 2 partitions /dev/sde2, /dev/sdd2 and then mkfs.etx4 the newly created /dev/md0 device. From performance point of view is it better to keep the configuration of mdadm and just format the /dev/md0 device as btrfs OR delete the raid device and format the 2 partitions /dev/sde2 /dev/sdd2 as a btrfs with 2 devices? mkfs.btrfs /dev/sde2 /dev/sdd2 On a sidenote: If I decide to go for raid5 which is not supported currently from mkfs I have to use the mdadm tool anyway, right? -- Caution: breathing may be hazardous to your health. -- 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
Re: Raid0 with btrfs
On Thursday 05 August 2010 16:15:22 Leonidas Spyropoulos wrote: Hi all, I want to make a btrfs raid0 on 2 partitions of my pc. Until now I am using the mdadm tools to make a software raid of the 2 partitions /dev/sde2, /dev/sdd2 and then mkfs.etx4 the newly created /dev/md0 device. From performance point of view is it better to keep the configuration of mdadm and just format the /dev/md0 device as btrfs OR delete the raid device and format the 2 partitions /dev/sde2 /dev/sdd2 as a btrfs with 2 devices? mkfs.btrfs /dev/sde2 /dev/sdd2 Btrfs already supports metadata mirroring when the data is striped. What this means, is while the performance should be more-or-less identical to MD RAID0 (if it isn't it's a bug), your data is a bit more secure as the metadata describing it resides on both drives. Later on it will be possible to selct which directories/files should have what level of redundancy. This will allow to have ~/work RAID1-ed and ~/videos RAID0-ed while keeping both directories on the same partition and filesystem. On a sidenote: If I decide to go for raid5 which is not supported currently from mkfs I have to use the mdadm tool anyway, right? yes, RAID5 code is not in trunk yet. -- 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
