Re: Kernel 3.7 + slower snapshot then usual
On wed, 12 Dec 2012 23:26:02 -0500, Sylvain Alain wrote: Hi guys, I noticed that now my snapshot take a long time to process : sylvain@gentootux ~ $ df -h Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur rootfs 112G4,0G 103G 4% / /dev/sda4 112G4,0G 103G 4% / tmpfs 7,9G596K 7,9G 1% /run udev10M 0 10M 0% /dev none 7,9G 0 7,9G 0% /dev/shm cgroup_root 10M 0 10M 0% /sys/fs/cgroup tmpfs 12G 0 12G 0% /var/tmp/portage /dev/sdb2 224G 52G 173G 23% /mnt/win_c /dev/sdc2 912G412G 500G 46% /mnt/win_d sylvain@gentootux ~ $ su - Mot de passe : gentootux ~ # mount /dev/sda4 -o noatime,ssd,discard,compress=lzo,noacl,space_cache,subvolid=0 /mnt/disklayout/ gentootux ~ # cd /mnt/disklayout/ gentootux disklayout # ls @backup @racine gentootux disklayout # time btrfs subvolume delete @backup Delete subvolume '/mnt/disklayout/@backup' real 0m0.020s user 0m0.001s sys 0m0.002s gentootux disklayout # ls @racine gentootux disklayout # time btrfs subvolume snapshot @racine @backup Create a snapshot of '@racine' in './@backup' real 6m9.122s user 0m0.000s sys 0m0.523s more then 6 minutes to snapshot 4 gigs of data, that's twice slower then kernel 3.6. Is there any log or something that I look after ? sylvain@gentootux ~ $ sudo dmesg | grep -i btrfs [0.371528] Btrfs loaded [0.784593] btrfs: disk space caching is enabled [0.788680] Btrfs detected SSD devices, enabling SSD mode [0.789757] VFS: Mounted root (btrfs filesystem) readonly on device 0:12. [4.881241] btrfs: use ssd allocation scheme [4.881244] btrfs: use lzo compression [4.881245] btrfs: disk space caching is enabled [ 496.982616] btrfs: unlinked 14 orphans What kind of kernel did you use? mainline kernel? Thanks Miao -- 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: Encryption
merc1...@f-m.fm wrote (ao): Oh pardon me, it's BTRFS RAID that's a no-go, which is just as critical to me as I have a 4 disk 8TB array. The FAQ goeth on to Say: --- This pretty much forbids you to use btrfs' cool RAID features if you need encryption. Forbids? That is just plain wrong. I have one btrfs filesystem on top of two encrypted devices. Works just fine. Sander -- 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
[btrfs] is vulnerable to a hash-DoS attack
Hello folk, The btrfs file system, part of the linux kernel, is vulnerable to a trivial hash-DoS attack. More details can be found here: http://crypto.junod.info/2012/12/13/hash-dos-and-btrfs/ Enjoy! Pascal Junod -- http://crypto.junod.info @cryptopathe -- 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: no activity in kernel.org btrfs-progs git repo?
On Wed, Dec 12, 2012 at 04:41:50PM -0700, Zach Brown wrote: On Thu, Dec 13, 2012 at 04:50:54AM +0530, Nirbheek Chauhan wrote: On Thu, Dec 13, 2012 at 4:21 AM, Hugo Mills h...@carfax.org.uk wrote: Two things: *nod* I think Zach was asking about the userspace tools, not the kernel module. But yes, I was asking about -progs :). Yes, I've got the big raid56 push ready to go out, and I've just been trying to test it all. I'll put that in a raid branch and get the fixes onto master. -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: Encryption
On Thu, Dec 13, 2012, at 1:17, Sander wrote: Forbids? That is just plain wrong. I have one btrfs filesystem on top of two encrypted devices. Works just fine. That's dynamite Sander. But I am not going to contravene the instructions, then have problems, only to come back here and have fingers wagged in my face telling me this is all EXPERIMENTAL! -- http://www.fastmail.fm - Send your email first class -- 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: no activity in kernel.org btrfs-progs git repo?
On Thu, Dec 13, 2012 at 09:56:10AM -0500, Chris Mason wrote: Yes, I've got the big raid56 push ready to go out, and I've just been trying to test it all. I'll put that in a raid branch and get the fixes onto master. Thanks. I was asking because it's pretty annoying to go through patchwork to see if someone else has already fixed bugs in the git tree. This happened to me when our distro package infrastructure freaked out at btrfs-progs (-fno-strict-aliasing, int/ptr differences, static code analysis lighting up a like a christmas tree). Would it be fair to say that the project is accepting applications for an active btrfs-progs maintainer? :) - z -- 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: [btrfs] is vulnerable to a hash-DoS attack
[ adding linux-btrfs ] On Thu, Dec 13, 2012 at 05:56:37AM -0700, Pascal Junod wrote: Hello folk, The btrfs file system, part of the linux kernel, is vulnerable to a trivial hash-DoS attack. More details can be found here: http://crypto.junod.info/2012/12/13/hash-dos-and-btrfs/ Hi Pascal, Thanks for taking the time to write this up. As far as I can tell, the looping was actually fixed in an older kernel and I just misread our version string in your original email. I'll track down the commit that fixed things and send it off to the stable series. SuSE and Fujitsu have done a number of error handling cleanups, it should be one of those. -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: no activity in kernel.org btrfs-progs git repo?
On Thu, Dec 13, 2012 at 12:50:40PM -0700, Zach Brown wrote: On Thu, Dec 13, 2012 at 09:56:10AM -0500, Chris Mason wrote: Yes, I've got the big raid56 push ready to go out, and I've just been trying to test it all. I'll put that in a raid branch and get the fixes onto master. Thanks. I was asking because it's pretty annoying to go through patchwork to see if someone else has already fixed bugs in the git tree. This happened to me when our distro package infrastructure freaked out at btrfs-progs (-fno-strict-aliasing, int/ptr differences, static code analysis lighting up a like a christmas tree). Would it be fair to say that the project is accepting applications for an active btrfs-progs maintainer? :) Well, the problem is the active maintainer is busy piling in other features. But yeah, I need to pull in the fixes, sorry. -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: [btrfs] is vulnerable to a hash-DoS attack
On Thu, Dec 13, 2012 at 03:52:08PM -0500, Chris Mason wrote: Thanks for taking the time to write this up. As far as I can tell, the looping was actually fixed in an older kernel and I just misread our version string in your original email. Yeah, the blogpost says 3.3.7. I did a quick test with 3.7 and was not able to reproduce it. david -- 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: [btrfs] is vulnerable to a hash-DoS attack
On Thu, Dec 13, 2012 at 02:34:30PM -0700, David Sterba wrote: On Thu, Dec 13, 2012 at 03:52:08PM -0500, Chris Mason wrote: Thanks for taking the time to write this up. As far as I can tell, the looping was actually fixed in an older kernel and I just misread our version string in your original email. Yeah, the blogpost says 3.3.7. I did a quick test with 3.7 and was not able to reproduce it. I tried with 3.3 and every step between 3.3 and 3.7. I'm not able to reproduce the problem, and I did run with Hack=True in the script (thanks for the flag btw, I really like that). So, that leaves us with a few possibilities: 1) mount -o seclabel 2) The small size of the device 3) loopback I ran with a 1GB FS here on 3.3 and wasn't able to trigger things. But Pascal, could you please help narrow the problem down? -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: Encryption
On Thu, Dec 13, 2012 at 09:23:05AM -0800, merc1...@f-m.fm wrote: On Thu, Dec 13, 2012, at 1:17, Sander wrote: Forbids? That is just plain wrong. I have one btrfs filesystem on top of two encrypted devices. Works just fine. That's dynamite Sander. But I am not going to contravene the instructions, then have problems, only to come back here and have fingers wagged in my face telling me this is all EXPERIMENTAL! Well, I'm afraid that applies to the information on the wiki, too -- that's also experimental, to a degree. The notes on the wiki about behaviour of encryption layers weren't added by any of the core developers. Nobody's published concrete tests *either* way yet, and those comments are one person's opinion, as far as I'm aware (and note that they don't actually quote sources, results, or even personal experience). YMMV. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Great oxymorons of the world, no. 2: Common Sense --- signature.asc Description: Digital signature
