Re: missing /sbin/fsck.btrfs
On 11/26/2013 04:18 PM, Duncan wrote: Chris Murphy posted on Mon, 25 Nov 2013 23:40:49 -0700 as excerpted: Is there supposed to be an /sbin/fsck.btrfs? I'm seeing a handful of threads indicating some idea of having it just do a no-op like fsck.xfs does, but then also the idea that /etc/fstab should correctly set fs_passno to 0 instead of such trickery. I ask due to systemd-fstab-generator seemingly getting the idea from Fedora 20's default /etc/fstab that btrfs should have its file system checked, and during offline updates, systemd tries to do this, doesn't find /sbin/fsck.btrfs, and then has several dozen fits. https://bugzilla.redhat.com/show_bug.cgi?id=1034563 https://bugzilla.redhat.com/show_bug.cgi?id=862871 So the question, is there supposed to be (one day) a faux /sbin/fsck.btrfs? Or should things always check /etc/fstab fs_passno and honor the fact there is really no such thing? Just symlink/copy fsck.btrfs to (/bin/)true. https://btrfs.wiki.kernel.org/index.php/FAQ#What.27s_the_difference_between_btrfsck_and_fsck.btrfs Or just do the /etc/fstab fs_passno = 0 thing, which is what I did with reiserfs, so no change in that regard here when I switched to btrfs for most partitions. But I'm on gentoo and haven't opted to drink the systemd koolaid yet, so what it thinks about that I wouldn't know. I think it is better to symlink to true, because otherwise mkinitramfs in the default configuration will be complaining about the missing hook (can be ignored of course) -- 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: swapfile on btrfs, temporary solution for wiki
On 10/25/2013 05:52 AM, Timofey Titovets wrote: Hello, i suggest temporary solution to use swap file under btrfs. I test it, and it work good. I invent simple the way, how create and using swap file, just see following sh code: swapfile=$(losetup -f) #free loop device truncate -s 8G /swap #create 8G sparse swap file losetup $swapfile /swap #mount file to loop mkswap $swapfile swapon $swapfile i just adding this to rc.local and this work good. May be, add it to btrfs Wiki as temporary solution to using swap file? Timofey Hi, Yes, Timofey, it does work. I tested the same over a year ago. And it does say briefly about this option in wiki https://btrfs.wiki.kernel.org/index.php/FAQ#Does_btrfs_support_swap_files.3F "A workaround, albeit with poor performance, is to mount a swap file via a loop device." best -- 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-ino-cache is running on each reboot
On 08/14/2013 12:37 AM, Josef Bacik wrote: On Tue, Aug 13, 2013 at 10:28:59AM +0900, dima wrote: Hello all, About a week or so ago I noticed that [btrfs-ino-cache] process was appearing in the 'top' on each reboot and disk is spinning like crazy for about five minutes or so. Quite so often this caused X failing to start because all I/O was busy with caching. Even after letting it to calm down and seeing [btrfs-ino-cache] disappearing from the process list, on next reboot it starts all over again. Here is the fstab entry that I have UUID=430dca92-9541-4201-0f62-373e30beadac / btrfs subvol=root_subvolume,defaults,noatime,noacl,compress=lzo,inode_cache,space_cache,autodefrag 0 0 inode_cache was always enabled since the FS was created about a year or so ago, and actually I have never had any problems with it up until recently. Removing inode_cache option from fstab solves the problem, but I am not sure if it is the right choice. I can observe the problem at least in the vanilla kernel 3.10.4 ~ 6 (did not try older versions) What could be the reason for such behavior and how to avoid it? That's odd. Can you apply patches and build kernels so I can try and narrow down what is happening? Thanks, Josef Hi Josef, Sure, I can do that. I am running archlinux with a vanilla kernel that I build myself. Thanks -- 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-ino-cache is running on each reboot
On 08/13/2013 01:09 PM, Duncan wrote: dima posted on Tue, 13 Aug 2013 10:28:59 +0900 as excerpted: About a week or so ago I noticed that [btrfs-ino-cache] process was appearing in the 'top' on each reboot and disk is spinning like crazy for about five minutes or so. Quite so often this caused X failing to start because all I/O was busy with caching. Even after letting it to calm down and seeing [btrfs-ino-cache] disappearing from the process list, on next reboot it starts all over again. inode_cache was always enabled since the FS was created about a year or so ago, and actually I have never had any problems with it up until recently. Removing inode_cache option from fstab solves the problem, but I am not sure if it is the right choice. A number of people have reported problems with inode_cache enabled, and the recommendation has always been to turn it off "unless you need it". Easy enough problem to fix, I guess. =:^) Of course that immediately invites the question of why have the option at all if all it does is cause trouble, and (as a user not a dev) I don't have the answer to that. I don't know the use case when "unless you need it" would actually apply, but apparently, it does in some cases. I guess the wiki[1] should really have a warning on that option, but without a more solid reason than "just don't turn it on, causes more trouble than it's worth", I'd feel kind of goofy adding it. Anyway, yes, the general recommendation on the list at this point seems to be to simply leave inode_cache off and not worry about it. Thanks Duncan. So I did. I was just wondering why it stopped behaving all of a sudden. --- [1] https://btrfs.wiki.kernel.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
btrfs-ino-cache is running on each reboot
Hello all, About a week or so ago I noticed that [btrfs-ino-cache] process was appearing in the 'top' on each reboot and disk is spinning like crazy for about five minutes or so. Quite so often this caused X failing to start because all I/O was busy with caching. Even after letting it to calm down and seeing [btrfs-ino-cache] disappearing from the process list, on next reboot it starts all over again. Here is the fstab entry that I have UUID=430dca92-9541-4201-0f62-373e30beadac / btrfs subvol=root_subvolume,defaults,noatime,noacl,compress=lzo,inode_cache,space_cache,autodefrag 0 0 inode_cache was always enabled since the FS was created about a year or so ago, and actually I have never had any problems with it up until recently. Removing inode_cache option from fstab solves the problem, but I am not sure if it is the right choice. I can observe the problem at least in the vanilla kernel 3.10.4 ~ 6 (did not try older versions) What could be the reason for such behavior and how to avoid it? thanks -- 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: Best Practice - Partition, or not?
On 05/01/2013 05:44 PM, Russell Coker wrote: On Wed, 1 May 2013, dima wrote: If I want to manage a complete disk with btrfs, what's the "Best Practice"? Would it be best to create the btrfs filesystem on "/dev/sdb", or would it be better to create just one partition from start to end and then do "mkfs.btrfs /dev/sdb1"? Would the same recomendation hold true, if we're talking about huge disks, like 4TB or so? My biggest BTRFS array is a RAID-1 of 2*3TB disks. The system in question boots from an Intel SSD so I have no need of boot support on the hard disks. (NB: grub will not boot from "/dev/sdb", selinux will) Not sure what you mean here, but SE Linux isn't a boot loader. Did you mean syslinux? That's a boot loader but I don't know if it works in such a configuration. gosh! of course, SYSLINUX. Sorry guys. (i am working with selinux just now that is why) Yes, syslinux will work, I had an install with root btrfs with syslinux as a bootloader (at the time when grub2 did not support booting from btrfs) -- 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: Best Practice - Partition, or not?
On 05/01/2013 04:51 PM, Alexander Skwar wrote: Hello If I want to manage a complete disk with btrfs, what's the "Best Practice"? Would it be best to create the btrfs filesystem on "/dev/sdb", or would it be better to create just one partition from start to end and then do "mkfs.btrfs /dev/sdb1"? Would the same recomendation hold true, if we're talking about huge disks, like 4TB or so? Cross platform compatibility (OS X, Windows, FreeBSD, …) is of no matter to me. Thanks, Alexander (NB: grub will not boot from "/dev/sdb", selinux will) -- 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: File space cache
On 03/13/2013 05:53 PM, Hugo Mills wrote: On Wed, Mar 13, 2013 at 02:31:27PM +0900, dima wrote: Hello Alex, On 03/13/2013 01:17 AM, Alex wrote: Hi All, It seems my btrfs file space cache is corrupt; I had to run clear the log through a kernel problem. I've seen messages that the cache is rebuilt automatically, but this doesn't seem to be true as the messages that the free space is what is expected keep coming. I'm running kernel 3.8.2 (Siduction) on Debian testing. I believe you may try clear_cache mount option https://btrfs.wiki.kernel.org/index.php/Mount_options As a subsidiary question, please, should the value in fstab be zero or non-zero? It should be zero. But since fsck.btrfs is non-existent, it does not really matter I guess. Eh? We've had a functional btrfsck for nearly a year. Right. But it is not something that you run on boot, is it. That is why I mentioned fsck.btrfs Hugo. -- 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: File space cache
Hello Alex, On 03/13/2013 01:17 AM, Alex wrote: Hi All, It seems my btrfs file space cache is corrupt; I had to run clear the log through a kernel problem. I've seen messages that the cache is rebuilt automatically, but this doesn't seem to be true as the messages that the free space is what is expected keep coming. I'm running kernel 3.8.2 (Siduction) on Debian testing. I believe you may try clear_cache mount option https://btrfs.wiki.kernel.org/index.php/Mount_options As a subsidiary question, please, should the value in fstab be zero or non-zero? It should be zero. But since fsck.btrfs is non-existent, it does not really matter I guess. ~dima Kind regards. Al. -- 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 -- 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: partition question
I don't know this area of the code at all well, but as I understand it, there's been some work in the kernel (swap over NFS) which lays down some of the underlying infrastructure we'd need to support swapfiles on btrfs, but we don't have anything beyond that. I don't know of anyone working on it, either. Hugo. You can use swapfile on btrfs with mounting it via a loop device. It won't be incredibly fast, but it will work. -- 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: problems with dracut mounting subvols
On 12/28/2012 10:44 AM, Chris Murphy wrote: On Dec 27, 2012, at 6:13 PM, dima wrote: /dev/disk/by-uuid/64383cfe-c31d-4d25-97c4-4e6b7e788b26 /sysroot/usr btrfs subvol=usr,subvol=root,ro 1 2 I'd say that the problem is definitely with this line having two subvolumes listed. Maybe you should boot from a live CD, mount your subvolid=1 and check out what subvolumes you really have in there. And then re-write fstab manually. When I mount subvolid=5 there are subvols root, boot, usr, var, home. And the /etc/fstab in root is: # # /etc/fstab # Created by anaconda on Thu Dec 27 15:21:03 2012 # # Accessible filesystems, by reference, are maintained under '/dev/disk' # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info # UUID=64383cfe-c31d-4d25-97c4-4e6b7e788b26 / btrfs subvol=root 1 1 UUID=64383cfe-c31d-4d25-97c4-4e6b7e788b26 /boot btrfs subvol=boot 1 2 UUID=64383cfe-c31d-4d25-97c4-4e6b7e788b26 /home btrfs subvol=home 1 2 UUID=64383cfe-c31d-4d25-97c4-4e6b7e788b26 /usrbtrfs subvol=usr 1 2 UUID=64383cfe-c31d-4d25-97c4-4e6b7e788b26 /varbtrfs subvol=var 1 2 It's correct. Seems dracut is creating the wrong fstab for itself, but then also can't mount it correctly manually from a shell command. When booted in rescue mode to a full system, not just a dracut shell, I can mount -o subvol=root to one mount point, and also mount -o subvol=usr to another mountpoint (within or outside the former mount point) without error. Then I guess all is fine with subvolumes and something is strange with the way fedora is handling those. Because it is the temporary ro mount that fails. The only thing I can recommend is to first create all needed subvolumes, then install the minimal OS manually from CLI and configure your grub and fstab by hand. Can't really help with dracut troubleshooting.. If you have /sysroot subvolume, you can create /sysroot/usr as a child subvolume and you won't even need then to specify /sysroot/usr in your fstab because it will be mounted automatically when the parent subvolume gets mounted. It's a useful work around. I'd like to narrow down if the real problem is dracut and if it should eventually be fixed. Seems both need fixing. Chris Murphy-- 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 -- 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: problems with dracut mounting subvols
I've just tried putting usr in a subvol. Installation proceeds normally, no errors, but I'm dropped to a dracut prompt which indicates mount of /usr failed. dmesg follows: [ 14.025215] systemd[1]: Starting dracut initqueue hook... [ 14.077890] Btrfs loaded [ 14.129987] device label fedora_f18v devid 1 transid 31 /dev/sda1 [ 14.313607] device label fedora_f18v devid 1 transid 31 /dev/sda1 [ 14.446523] systemd[1]: Started Show Plymouth Boot Screen. [[1;32m OK [[ 14.533662] btrfs: disk space caching is enabled 0m] Started Show Plymouth Boot Screen. [ 14.534404] systemd[1]: Started Dispatch Password Requests to Console Directory Watch. [ 14.534886] systemd[1]: Starting Forward Password Requests to Plymouth Directory Watch. [ 14.535001] systemd[1]: Started Forward Password Requests to Plymouth Directory Watch. [ 14.535067] systemd[1]: Starting Basic System. [[1;32m OK [0m] Reached target Basic System.[ 15.053733] systemd[1]: Reached target Basic System. [ 15.094806] device label fedora_f18v devid 1 transid 31 /dev/sda1 [ 15.251736] btrfs: disk space caching is enabled [ 15.430129] systemd[1]: Started dracut initqueue hook. [ 15.574280] systemd[1]: Starting dracut pre-pivot and cleanup hook... [ 15.735181] device label fedora_f18v devid 1 transid 31 /dev/sda1 [ 15.876950] btrfs: 'root' is not a valid subvolume dracut-pre-pivot[228]: Warning: Mounting /usr to /sysroot/usr failed dracut-pre-pivot[228]: Warning: *** Dropping you to a shell; the system will continue dracut-pre-pivot[228]: Warning: *** when you leave the shell. dracut-pre-pivot[228]: Warning: [[1;32m OK [0m] Started Show Plymouth Boot Screen. [[1;32m OK [0m] Reached target Basic System. dracut-pre-pivot[228]: Warning: Mounting /usr to /sysroot/usr failed dracut-pre-pivot[228]: Warning: *** Dropping you to a shell; the system will continue dracut-pre-pivot[228]: Warning: *** when you leave the shell. dracut-pre-pivot[228]: Warning: [ 16.314849] systemd[1]: Starting Emergency Shell… After a bit of snooping I found the dracut fstab suspicious: dracut:/# cat /etc/fstab /dev/disk/by-uuid/64383cfe-c31d-4d25-97c4-4e6b7e788b26 /sysroot btrfs subvol=root,ro 0 /dev/disk/by-uuid/64383cfe-c31d-4d25-97c4-4e6b7e788b26 /sysroot/usr btrfs subvol=usr,subvol=root,ro 1 2 Two mount options, mounting two subvols to the same mount point? Seems problematic. But even when I try what I think is correct from a dracut prompt: dracut:/# mount -o subvol=usr /dev/sda1 /sysroot/usr mount: /dev/sda1 is already mounted or /sysroot/usr busy /dev/sda1 is already mounted on /sysroot The only sda device mounted at this time is the root subvol to /sysroot. So the additional question is if dracut maybe has a problem with multiple physical devices being mounted more than once, which is what happens when mounting multiple subvols? This is dracut-024-17.git20121220.fc18. Seems like maybe two bugs? /dev/disk/by-uuid/64383cfe-c31d-4d25-97c4-4e6b7e788b26 /sysroot/usr btrfs subvol=usr,subvol=root,ro 1 2 I'd say that the problem is definitely with this line having two subvolumes listed. Maybe you should boot from a live CD, mount your subvolid=1 and check out what subvolumes you really have in there. And then re-write fstab manually. If you have /sysroot subvolume, you can create /sysroot/usr as a child subvolume and you won't even need then to specify /sysroot/usr in your fstab because it will be mounted automatically when the parent subvolume gets mounted. -- 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: device delete, error removing device
On 10/22/2012 01:32 PM, Chris Murphy wrote: Summary: 3 drive raid0 btrfs volume, in a VM. There is no data at risk at all. Purely a test. The volume is pretty much full. I added a larger drive /dev/sde to the existing btrfs volume; then tried to remove one of the smaller drives. I'm getting an error removing the device. It seems this should be possible, e.g. move extents on a failing device to a replacement prior to failure. This is stock Fedora 18 beta kernel, 3.6.1-1.fc18.x86_64 #1 SMP Mon Oct 8 17:19:09 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux [root@f18v ~]# btrfs device add /dev/sde /mnt [root@f18v ~]# btrfs fi show failed to read /dev/sr0 Label: none uuid: 6e96a96e-3357-4f23-b064-0f0713366d45 Total devices 4 FS bytes used 7.52GB devid4 size 12.00GB used 0.00 path /dev/sde devid3 size 3.00GB used 3.00GB path /dev/sdd devid2 size 3.00GB used 2.55GB path /dev/sdc devid1 size 3.00GB used 3.00GB path /dev/sdb [root@f18v ~]# btrfs fi df /mnt Data, RAID0: total=7.61GB, used=7.51GB System, RAID1: total=8.00MB, used=4.00KB Metadata, RAID1: total=460.75MB, used=10.91MB [root@f18v ~]# btrfs device delete /dev/sdb /mnt ERROR: error removing the device '/dev/sdb' - No space left on device [ 570.379652] btrfs: relocating block group 29360128 flags 20 [ 571.739126] btrfs: found 2717 extents [ 571.761061] btrfs: relocating block group 12582912 flags 1 [ 571.787233] btrfs: relocating block group 4194304 flags 4 [ 571.806878] btrfs: relocating block group 0 flags 2 Some time later (hours), I unmounted, remounted, and see this: [root@f18v ~]# btrfs fi show failed to read /dev/sr0 Label: none uuid: 6e96a96e-3357-4f23-b064-0f0713366d45 Total devices 4 FS bytes used 7.52GB devid4 size 12.00GB used 460.75MB path /dev/sde devid3 size 3.00GB used 2.55GB path /dev/sdd devid2 size 3.00GB used 3.00GB path /dev/sdc devid1 size 3.00GB used 2.53GB path /dev/sdb Subsequent attempts cause the same failure, but no new entries in dmesg. If I try with a different device, there is activity, but after a few seconds, another failure, similar errors in dmesg: [root@f18v ~]# btrfs device delete /dev/sdc /mnt ERROR: error removing the device '/dev/sdc' - No space left on device [ 2478.017828] btrfs: relocating block group 8955363328 flags 20 [ 2478.059607] btrfs: relocating block group 8686927872 flags 20 [ 2479.405142] btrfs: found 2735 extents [ 2479.436190] btrfs: relocating block group 8663859200 flags 9 [ 2479.458680] btrfs: relocating block group 8243118080 flags 9 [ 2481.949991] btrfs: found 4 extents [ 2482.700146] btrfs: found 4 extents [ 2482.717422] btrfs: relocating block group 20971520 flags 18 [ 2482.733835] btrfs: found 1 extents User error? Known bug? Might be you need to balance first after adding a new disk btrfs filesystem balance /mnt -- 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: KVM on top of BTRFS
On 06/12/2012 08:53 AM, Alex wrote: Matthew Hawn yahoo.com> writes: What are the recommendations for running KVM images on BTRFS systems using kernel 3.4? I saw older posts on the web complaining about poor performance, but I know a lot of work has gone into btrfs since then. There also seemed to be the nocow option, but I didn't find anything that said it actualy helped. I don't think it is about the kernel version, but rather about choosing the right option for KVM. I am running KVM via libvirt on btrfs with lzo compression, autodefrag, inode and space cache for quite some time. Yes, I did set nocow for the directory with images. I have no proof that it actually helps with disk images, but being set for the build directory my build time is down 5 minutes. I used raw virtio images with no caching. I guess this is the key if we talk about disk I/O. The performance looks fine, though I only use it for testing. The last time I tried to install WinXP on KVM it was a disaster. But I guess I did not choose the right options, nor did I install virtio drivers inside the guest. VirtualBox still outperforms KVM on btrfs in my view. best -- 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: Set nodatacow per file?
On 02/28/2012 09:51 AM, dima wrote: On 02/28/2012 07:10 AM, Chester wrote: On Mon, Feb 27, 2012 at 7:54 AM, dima wrote: Hello, Since several people asked to post the results, here they are. I tried raw virtio disk with and without -z -C set and also qcow2 virtio disk without -z -C set and did not notice any difference in performance at all - Redhat 6.2 Minimal installs in 10 minutes in each case. The "abysmal" performance as it was some several months ago (like 10 minutes just for virtual disk formatting) under the same conditions is no more at least on 3.3.0-rc5. Just to make sure, this is a _new_ virtual disk right? I can barely contain my excitement right now. This is amazing progress. Yes, it is a newly created virtual disk. By the way, one thing that slipped out from my message - in case of raw I did pre-allocation of the entire image, but in case of qcow2 I unchecked this box in virt-manager and the disk was "growing" as the system was installing. Nevertheless I did not notice performance degradation during the install. But still Virtualbox is faster. It installs Redhat 6 Minimal in just about 5 minutes. I observe that yum installations work faster. WindowsXP install under KVM was a hell lasting for about 3 hours and the performance is awful with host HD indicator flashing all the time. There was no change whatsoever whether the image was with +C +z or not. On Virtualbox WinXP install completed in about 25 minutes and the performance is excellent even w/o guest additions applied. I wonder why such a big difference. -- 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: Set nodatacow per file?
On 02/28/2012 07:10 AM, Chester wrote: On Mon, Feb 27, 2012 at 7:54 AM, dima wrote: Hello, Since several people asked to post the results, here they are. I tried raw virtio disk with and without -z -C set and also qcow2 virtio disk without -z -C set and did not notice any difference in performance at all - Redhat 6.2 Minimal installs in 10 minutes in each case. The "abysmal" performance as it was some several months ago (like 10 minutes just for virtual disk formatting) under the same conditions is no more at least on 3.3.0-rc5. Just to make sure, this is a _new_ virtual disk right? I can barely contain my excitement right now. This is amazing progress. Yes, it is a newly created virtual disk. By the way, one thing that slipped out from my message - in case of raw I did pre-allocation of the entire image, but in case of qcow2 I unchecked this box in virt-manager and the disk was "growing" as the system was installing. Nevertheless I did not notice performance degradation during the install. best ~dima -- 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: Set nodatacow per file?
Hello, Since several people asked to post the results, here they are. I tried raw virtio disk with and without -z -C set and also qcow2 virtio disk without -z -C set and did not notice any difference in performance at all - Redhat 6.2 Minimal installs in 10 minutes in each case. The "abysmal" performance as it was some several months ago (like 10 minutes just for virtual disk formatting) under the same conditions is no more at least on 3.3.0-rc5. best ~dima On 02/24/2012 02:22 PM, dima wrote: On 02/13/2012 04:17 PM, Ralf-Peter Rohbeck wrote: Hello, is it possible to set nodatacow on a per-file basis? I couldn't find anything. If not, wouldn't that be a great feature to get around the performance issues with VM and database storage? Of course cloning should still cause COW. Hello, Going back to the original question from Ralf I wanted to share my experience. Yesterday I set up KVM+qemu and set -z -C with David's 'fileflags' utility for the VM image file. I was very pleased with results - Redhat 6 Minimal installation was installed in 10 minutes whereas it was taking 'forever' the last time I tried it some 4 months ago. Writes during installation were very moderate. Performance of VM is excellent. Installing some big packages with yum inside VM goes very quickly with the speed indistinguishable from that of bare metal installs. I am not quite sure should this improvement be attributed to the nocow and nocompress flags or to the overall improvement of btrfs (I am on 3.3-rc4 kernel) but KVM is definitely more than usable on btrfs now. I am yet to test the install speed and performance without those flags set. best ~dima -- 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 -- 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: Set nodatacow per file?
On 02/13/2012 04:17 PM, Ralf-Peter Rohbeck wrote: Hello, is it possible to set nodatacow on a per-file basis? I couldn't find anything. If not, wouldn't that be a great feature to get around the performance issues with VM and database storage? Of course cloning should still cause COW. Hello, Going back to the original question from Ralf I wanted to share my experience. Yesterday I set up KVM+qemu and set -z -C with David's 'fileflags' utility for the VM image file. I was very pleased with results - Redhat 6 Minimal installation was installed in 10 minutes whereas it was taking 'forever' the last time I tried it some 4 months ago. Writes during installation were very moderate. Performance of VM is excellent. Installing some big packages with yum inside VM goes very quickly with the speed indistinguishable from that of bare metal installs. I am not quite sure should this improvement be attributed to the nocow and nocompress flags or to the overall improvement of btrfs (I am on 3.3-rc4 kernel) but KVM is definitely more than usable on btrfs now. I am yet to test the install speed and performance without those flags set. best ~dima -- 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: Set nodatacow per file?
On 02/13/2012 11:10 PM, David Sterba wrote: Hi, On Mon, Feb 13, 2012 at 04:40:03PM +0900, dima wrote: Actually it is possible. Check out David's response to my question from some time ago: http://permalink.gmane.org/gmane.comp.file-systems.btrfs/14227 this was a quick aid, please see attached file for an updated tool to set the file flags, now added 'z' for NOCOMPRESS flag, and supports chattr syntax plus all of the standard file flags. Setting and unsetting nocow is done like 'fileflags +C file' or -C for unseting. Without any + or - options it prints current state. david Thanks David. Perfect! This would be a great help. ~dima -- 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: Set nodatacow per file?
On 02/13/2012 05:09 PM, Roman Mamedov wrote:
On Mon, 13 Feb 2012 16:40:03 +0900
dima wrote:
Hello Ralf-Peter,
Actually it is possible. Check out David's response to my question from
some time ago:
http://permalink.gmane.org/gmane.comp.file-systems.btrfs/14227
The nocow.c script he attached does just the thing you want. The script
is really working. I needed nocow for different purpose but it did not
occur to me to try it on VM image and see if the performance would
improve. Sounds like a great idea. If you get around to try it, pls.
post your impressions here.
Thanks for the link, this is indeed interesting.
I made a couple of small changes, i.e. I wanted a way to unset nocow and to
check that changing flags really worked.
gcc -o /usr/local/bin/nocow nocow.c
ln -sf /usr/local/bin/nocow /usr/local/bin/cow
Perhaps the support for setting this flag should be added to the 'btrfs'
utility.
Hello Roman,
I don't seem to be able to 'unset' the NOCOW flag. Looking at the code
I would guess that it is supposed to alternate between 'cow' and 'nocow'
states, but the condition
printf("Remove NOCOW flag for %s\n", argv[1]);
never shows for me. What should I do to make it working?
Maybe it would be nice to have a switch to just check if nocow is set on
file without actually changing the flag.
thanks
~dima
--
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: Set nodatacow per file?
On 02/13/2012 05:09 PM, Roman Mamedov wrote: On Mon, 13 Feb 2012 16:40:03 +0900 dima wrote: Hello Ralf-Peter, Actually it is possible. Check out David's response to my question from some time ago: http://permalink.gmane.org/gmane.comp.file-systems.btrfs/14227 The nocow.c script he attached does just the thing you want. The script is really working. I needed nocow for different purpose but it did not occur to me to try it on VM image and see if the performance would improve. Sounds like a great idea. If you get around to try it, pls. post your impressions here. Thanks for the link, this is indeed interesting. I made a couple of small changes, i.e. I wanted a way to unset nocow and to check that changing flags really worked. gcc -o /usr/local/bin/nocow nocow.c ln -sf /usr/local/bin/nocow /usr/local/bin/cow Perhaps the support for setting this flag should be added to the 'btrfs' utility. Cool. Thanks Roma! I really wanted the feature to 'unset' the nocow and check the current state of flags. Will check it out today. I also think that it should definitely be included into the userspace btrfs utilities. best ~dima -- 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: Set nodatacow per file?
Hello Ralf-Peter, Actually it is possible. Check out David's response to my question from some time ago: http://permalink.gmane.org/gmane.comp.file-systems.btrfs/14227 The nocow.c script he attached does just the thing you want. The script is really working. I needed nocow for different purpose but it did not occur to me to try it on VM image and see if the performance would improve. Sounds like a great idea. If you get around to try it, pls. post your impressions here. best ~dima On 02/13/2012 04:17 PM, Ralf-Peter Rohbeck wrote: Hello, is it possible to set nodatacow on a per-file basis? I couldn't find anything. If not, wouldn't that be a great feature to get around the performance issues with VM and database storage? Of course cloning should still cause COW. Thanks, Ralf-Peter -- 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 -- 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: What is best practice when partitioning a device that holds one or more btr-filesystems
On 12/15/2011 05:25 PM, Sander wrote: dima wrote (ao): Maybe just skip partitioning altogether ;) +1 format the device to btrfs and use subvolumes instead of your usual partitions (some /boot restrictions apply). You won't be able to use grub2 though, but syslinux will work. Grub2 has btrfs support for quite some time now, which you are aware of I assume. Grub2 can't cope with / in a subvolume or something? No, btrfs has nothing to do with this. It is just that grub2 cannot be installed to a partition-less drive (at least 1 partition is needed), while syslinux can. -- 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: What is best practice when partitioning a device that holds one or more btr-filesystems
On 12/15/2011 03:51 AM, Wilfred van Velzen wrote: On Wed, Dec 14, 2011 at 7:21 PM, Mitch Harder wrote: On Wed, Dec 14, 2011 at 7:00 AM, Wilfred van Velzen wrote: What is best practice when partitioning a device that holds one or more btr-filesystems When it comes to "best practices" in btrfs filesystem layouts, your primary consideration should be to make yourself robust to potential filesystem failure. Of course this should be true of any storage arrangement. But if you're going to be playing with rc kernels and applying patches off the list, you might want to break it up into multiple partitions so as to mitigate the problem if one partition picks up a inconsistency. On the other hand, it's also good for people to use the volume and subvolume features. There's many different ways for people to make use of volumes and subvolumes, and it's good to explore those features. Well, of course there are different usecases for different situations. What I want to find out is, if you should partition differently when you are using btrfs compared to partitioning for the other older/regular filesystems for linux, for regular (production) usecases. Maybe just skip partitioning altogether ;) - format the device to btrfs and use subvolumes instead of your usual partitions (some /boot restrictions apply). You won't be able to use grub2 though, but syslinux will work. -- 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 subvolume quota limits
On 11/21/2011 06:50 AM, Karol Šebesta wrote: Hello, Is there any possibility to set quota limit for subvolume created in BTRFS pool as in Solaris ZFS? Hi Quotas are not implemented yet in btrfs as far as I know. ~dima -- 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: How to remount btrfs without compression?
On 11/10/2011 11:23 AM, dima wrote: On 11/10/2011 09:11 AM, David Sterba wrote: On Wed, Nov 09, 2011 at 10:01:13AM +0900, dima wrote: Just for the record - I could find a solution thanks to the btrfs wiki being online again. In Gotchas it says mount -o nodatacow also disables compression and indeed it does. Remounting with this option and re-saving the file makes it uncompressed. However, I could not find how to remount the filesystem afterwards without nodatacow. I saw this mentioned on irc today (that nodatacow diasables compression). There is a way how to turn off compression on a file -- with help of the NOCOW _file_ attribute, ie. you don't have to remount. * create the file, compression enabled * set NOCOW (with the attached single-purpose nocow.c utility) * btrfs fi defrag the_file Make sure you have enough free space for the uncompressed file size. You can compare the extent layout before and after the defrag with "filefrag -v" . Hello David, Thank you, I will try it out tonight. Is there any way to see if nocow attribute was set on a particular file, and is there any way to unset it? Hi David I tried the nocow utility. It worked. First I made sure to re-save the syslinux.cfg file while btrfs was mounted with lzo to ensure that it is compressed, then I set the NOCOW flag with your utility. Then I checked fragmentation of the file and since it was a small one it was not fragmented. So when I ran btrfs fi defrag syslinux.cfg it did not have any effect and file was not uncompressed. Then I simply re-saved the file and it got uncompressed fine since bootloader could read it on reboot. thanks -- 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: How to remount btrfs without compression?
On 11/10/2011 09:11 AM, David Sterba wrote: On Wed, Nov 09, 2011 at 10:01:13AM +0900, dima wrote: Just for the record - I could find a solution thanks to the btrfs wiki being online again. In Gotchas it says mount -o nodatacow also disables compression and indeed it does. Remounting with this option and re-saving the file makes it uncompressed. However, I could not find how to remount the filesystem afterwards without nodatacow. I saw this mentioned on irc today (that nodatacow diasables compression). There is a way how to turn off compression on a file -- with help of the NOCOW _file_ attribute, ie. you don't have to remount. * create the file, compression enabled * set NOCOW (with the attached single-purpose nocow.c utility) * btrfs fi defrag the_file Make sure you have enough free space for the uncompressed file size. You can compare the extent layout before and after the defrag with "filefrag -v" . Hello David, Thank you, I will try it out tonight. Is there any way to see if nocow attribute was set on a particular file, and is there any way to unset it? thanks ~dima -- 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: How to remount btrfs without compression?
On 11/09/2011 12:12 AM, Chris Mason wrote: On Tue, Nov 08, 2011 at 10:01:51AM -0500, Chris Mason wrote: On Tue, Nov 08, 2011 at 11:00:42AM +0900, dima wrote: On 11/08/2011 10:54 AM, Eric Griffith wrote: On 11/7/2011 8:52 PM, Fajar A. Nugraha wrote: On Tue, Nov 8, 2011 at 8:06 AM, Eric Griffith wrote: Edit your fstab, remove the compress flag, reboot. Tell btrfs to rebalance the system, reboot again. And I -THINK- that'll decompress all the files I think the original question was how to force uncompressed mode, whether specific to a file or to a whole filesystem, without having to reboot :) AFAIK there's no way to do that. Whoops! Misunderstood the question haha. Yeah, as far as decompressing just a single file; from what I've read, thats impossible. Eric, Fajar, Thanks. Understood. Yes, it is possible to remove the compress flag from fstab, reboot and even do not do any defragmentation/rebalancing - just re-save the file and it will be saved uncompressed. This works. But only with reboot... chattr -c on the file should work (followed by defrag or rewriting the file). I just retested and it seems to be broken right now. I'll track it down. Ok, I had forgotten. chattr -c clears the compression flag bug doesn't set the no compress flag. We looks like we need to patch chattr for this. -chris Just for the record - I could find a solution thanks to the btrfs wiki being online again. In Gotchas it says mount -o nodatacow also disables compression and indeed it does. Remounting with this option and re-saving the file makes it uncompressed. However, I could not find how to remount the filesystem afterwards without nodatacow. ~dima -- 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: How to remount btrfs without compression?
On 11/08/2011 10:54 AM, Eric Griffith wrote: On 11/7/2011 8:52 PM, Fajar A. Nugraha wrote: On Tue, Nov 8, 2011 at 8:06 AM, Eric Griffith wrote: Edit your fstab, remove the compress flag, reboot. Tell btrfs to rebalance the system, reboot again. And I -THINK- that'll decompress all the files I think the original question was how to force uncompressed mode, whether specific to a file or to a whole filesystem, without having to reboot :) AFAIK there's no way to do that. Whoops! Misunderstood the question haha. Yeah, as far as decompressing just a single file; from what I've read, thats impossible. Eric, Fajar, Thanks. Understood. Yes, it is possible to remove the compress flag from fstab, reboot and even do not do any defragmentation/rebalancing - just re-save the file and it will be saved uncompressed. This works. But only with reboot... -- 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: How to remount btrfs without compression?
On 11/07/2011 09:19 PM, Martin Steigerwald wrote: Am Montag, 7. November 2011 schrieb dima: Hello, Hi Dima, Is there any possibility to remount a compressed btrfs without any compression at all? Syslinux bootloader does not understand any btrfs compression and whenever I edit syslinux.cfg on my compressed / subvolume, the file becomes compressed and thus unreadable by syslinux on the next boot. I tried to remount / without the 'compress' option (and edit syslinux.cfg in uncompressed state) and while the "mount" command would not show compression any more, I can see in the /proc/mounts that compression is still there and the file still gets compressed after editing. But there seem to be no mount option like compress=none or something. The only workaround I found is to boot from a live CD mount / without any compression and re-save syslinux.cfg. Then it the file gets uncompressed. Are there any other options except for this workaround to temporarily remount btrfs without compression? What does lsattr show on the file? Have you tried chattr -c on the file? It might help to do a btrfs filesystem defrag on the file to remove compression, cause I don´t think chattr -c itself will uncompress it. Hi Martin, Thanks for your reply. Yes, I did check out lsattr. It shows that no flags are set. Setting chattr +c then chattr -c and re-saving file has no effect either. I also tried to defragment the file itself and the directory where it was in without setting -c but it would not have any effect because / is mounted with compression. As far as I understand it is possible to individually set compression on/off on single files. Could not find how to turn it off though. thanks -- 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
How to remount btrfs without compression?
Hello, Is there any possibility to remount a compressed btrfs without any compression at all? Syslinux bootloader does not understand any btrfs compression and whenever I edit syslinux.cfg on my compressed / subvolume, the file becomes compressed and thus unreadable by syslinux on the next boot. I tried to remount / without the 'compress' option (and edit syslinux.cfg in uncompressed state) and while the "mount" command would not show compression any more, I can see in the /proc/mounts that compression is still there and the file still gets compressed after editing. But there seem to be no mount option like compress=none or something. The only workaround I found is to boot from a live CD mount / without any compression and re-save syslinux.cfg. Then it the file gets uncompressed. Are there any other options except for this workaround to temporarily remount btrfs without compression? thanks -- 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: Unable to mount btrfs partition
On 10/29/2011 08:45 AM, em...@joachim-neu.de wrote: On Fri, 28 Oct 2011 22:09:47 +0100, Hugo Mills wrote: On Fri, Oct 28, 2011 at 08:36:28PM +, em...@joachim-neu.de wrote: Today I downgraded from Ubuntu's APT repo "oneiric-proposed" (which brings some kernel 3.0.0-13) back to the standard repo "oneiric". It's odd that switching from one 3.0.0 to another would cause something bad to happen. Did something else happen in the process, like a reboot without a clean shutdown? (This includes power loss, suspend and failure to resume, and Alt-SysRq-b). I agree, but there was no power loss or anything. Maybe the fs didn't unmount correctly or fast enough when rebooting? Now I'm not able to mount my btrfs / and /home (both on the same partition) anymore: device fsid SOME-UUID devid 1 transid 84229 /dev/dm-0 parent transid verify failed on 77078528 wanted 83774 found 84226 parent transid verify failed on 77078528 wanted 83774 found 84226 parent transid verify failed on 77078528 wanted 83774 found 84226 parent transid verify failed on 77078528 wanted 83774 found 84226 btrfs: open_ctree failed The boot process drops to the initramfs shell with no btrfsck available. It wouldn't make any difference if it were -- btrfsck doesn't actually fix anything, I'm afraid. This error message is regrettably generic, and covers a whole range of evils. It's possible that 3.1 may be able to deal swith the breakage ufficiently well to allow you to boot and copy your files. I'll give the 3.1 kernel a try right after "restore" finished which is running right now and doing quite a good job so far (as far as my / is concerned, lets wait for the /home). You should definitely try 3.1. There are many improvements for btrfs. What errors are you getting on the screen and in your logs when you try to mount your subvolumes manually when booting from a live CD? Are / and /home in different subvolumes by the way? What do the above error messages indicate? Try to google it. It looks like pretty common error that can be caused by a bunch of things as Hugo mentioned. Is there an incrementing number for every transaction and the number of the most recent transaction is stored somewhere and those messages occur once those numbers are out of sync somehow? Is it possible to "just" discard the last transactions? I would not mind, better loose a day than a month... Why is the message there three times? Is this information stored in a couple of backups? If so: can't I use any of the other backups temporarily? "restore" opens the fs in a ro recovery mode somehow where it ignores those errors. Is it possible to "force" the btrfs driver to load the fs in this recovery mode as readonly, too? I don't think anything of this is possible. ~d -- 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: Unable to mount (or, why not to work late at night).
On 10/28/2011 09:32 AM, Ken D'Ambrosio wrote: some of us make use of snapshot/clone, whether it's using btrfs or zfs :) No, this is just flat my fault: it doesn't matter what backup method you use if you do it wrong. (I actually have three snapshots of each of my two partitions.) What do you mean don't let you do anything? Can you mount it read-only and copy the data off the disk? You can mount it on the older kernels, but, once you try any form of access, you can watch your load spike as it spews errors into dmesg. I'd try 3.1. If you use 11.10 try http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.1-oneiric/ 3.1 is what the system had been running; it simply panics when trying to mount the FS. Hello Ken, Personally I would be very afraid to go from 3.1 to 2.6.x. There should be no incompatible changes, but still I would expect all sorts of trouble and instability at the very least. There are a few mount options that were added in 3.x and that will not work with older kernels. Might be you are hitting those as well if you used them (just wild guessing without any real grounds). I would try getting the latest live CD with 3.1 from somewhere and try to mount your various snapshots from there. You might as well be lucky and be able to mount some of your snapshots. The repair program from this list would be your last resort I think ( ~d -- 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: linux v3.1 with btrfs-work: oops when deleting files
On 10/26/2011 07:25 PM, Helmut Hullen wrote: Hallo, dima, Du meintest am 26.10.11: I'm trying to rm some files, this is what I get in dmesg: [30975.249519] [ cut here ] [30975.249529] WARNING: at fs/btrfs/extent-tree.c:4588 __btrfs_free_extent+0x3b7/0x7ed() [...] [30975.249604] Pid: 12291, comm: rm Tainted: G A C 3.1.0-00057- gc82b96b-dirty #6 Can you ls the directory where the problem files are located? What would the the output? I had a very similar problem but on 3.0.x kernel when several files suddenly got corrupted. This morning I've tried kernel 3.1; you remembder my problems with 1 disk. dd if=/dev/baddisk of=/dev/zero bs=8M conv=noerror showed some bad sectors. hdparm ... --write-sector /dev/baddisk seems to repair them (I use a loop which not only tests the sector which is shown via "dd" but also some sectors around this one) Rebooting the machine with kernel 3.1: I could delete the old entries which seemed to contain bad sectors. Fine. Running btrfsck from the "Hugo Mills" git branch: still some errors - see attachment "btrfsck.txt", especially the last lines; there seems to be a bug. Copying some *.mpg files from another place to the btrfs cluster: suddenly the system hangs, "dmesg" shows similar messages as above (from Kai Krakow). See second attachment "dmesg-1.txt". "halt" doesn't work, "reboot" doesn't work, "ctrl alt delete" doesn't work. Reboot via power switch. Again copying: there was (within 1 file) a long pause, but then copying worked. There's still hope ... Maybe the pause caused kernel oops #3 and #4 - see attachment "dmesg- 2.txt". Just to show the only big difference: now I've seen some problem(s) not related to "rm" but to "cp". Viele Gruesse! Helmut Hi Helmut, For me any command I tried to use on the corrupted files would give me the errors in dmesg, like in your case. And I could not get rid of the files in any way. So eventually I had to recreate the subvolume. I checked my disk at that time, but it did not show any bad sector errors, so I concluded it is the FS problem. In your case it may be just the errors caused by bad sectors on disk. But perhaps recreating subvolume would be a good step to find out what is wrong. ~d -- 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: linux v3.1 with btrfs-work: oops when deleting files
On 10/27/2011 02:40 AM, Kai Krakow wrote: I'm trying to rm some files, this is what I get in dmesg: [snip] Can you ls the directory where the problem files are located? What would the the output? I had a very similar problem but on 3.0.x kernel when several files suddenly got corrupted. I can run "find -type f" for directories I suspect corrupted files in, and I see errors in dmesg if it happens to contain bad files. But no oopses and the system remains stable. If I mount the filesystem read-only I can even read these files without oopses, this way I produced an rsync backup to my original partition I created the btrfs subvolume from. I see. Just to share my experience. I think I had a different case because I could not even read some 20-30 files (photos) on my /home subvolume and any attempt to access them via rm or ls would give me kernel oopses, though the system would not crash with 3.1 kernel. Unless I tried to access the corrupted files the filesystem was stable and my / subvolume was fine. So I backed up everything not-corrupted (I did have the backups for the corrupted files anyway) and created my /home subvolume anew. I deleted the old subvolume and most of the space was reclaimed. But btrfsck would still give me errors about inability to access some inode ( -- 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: linux v3.1 with btrfs-work: oops when deleting files
On 10/25/2011 01:48 PM, Kai Krakow wrote: Hello list! I'm trying to rm some files, this is what I get in dmesg: [30975.249519] [ cut here ] [30975.249529] WARNING: at fs/btrfs/extent-tree.c:4588 __btrfs_free_extent+0x3b7/0x7ed() [30975.249532] Hardware name: [30975.249535] Modules linked in: af_packet lm90 it87 hwmon_vid hwmon fuse snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss reiserfs zram(C) mperf loop emu10k1_gp sidewinder joydev nfs lockd auth_rpcgss nfs_acl tcp_cubic sunrpc ipv6 snd_usb_audio snd_usbmidi_lib gspca_sonixj gspca_main videodev usbhid 8250_pnp i82875p_edac edac_core sr_mod sg analog cdrom firewire_ohci firewire_core evdev pcspkr parport_pc floppy parport ns558 gameport i2c_i801 ne2k_pci 8390 8250 serial_core snd_mpu401 snd_mpu401_uart intel_agp e1000 crc_itu_t fan button intel_gtt agpgart processor thermal unix usb_storage hid [last unloaded: microcode] [30975.249604] Pid: 12291, comm: rm Tainted: G A C 3.1.0-00057- gc82b96b-dirty #6 Hello Kai, Can you ls the directory where the problem files are located? What would the the output? I had a very similar problem but on 3.0.x kernel when several files suddenly got corrupted. ~d -- 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: Snapshot rollback
On 10/25/2011 05:01 PM, Fajar A. Nugraha wrote: > On Tue, Oct 25, 2011 at 9:00 AM, dima wrote: >> Fajar A. Nugraha fajar.net> writes: >> >>> AFAIK you have three possible ways to use /boot on btrfs: >>> >>> (1) put /boot on subvolid=0, don't change the default subvolume. That >>> works, but all your snapshot/subvols will be visible under /boot. Some >>> people might not want that for estetic reason. >> >> Hi Fajar, >> I think I am doing just this, but my subvolumes are not visible under /boot. I >> have all my subvolumes set up like this: >> /path/to/subvolid_0/boot< a simple directory bind-mounted to / >> /path/to/subvolid_0/__active< my / subvolume >> /path/to/subvolid_0/__home< my /home subvolume > > Actually with that setup you're using option (3) that I described. > > That means all your subvolumes is still visible under > /path/to/subvolid_0/, right? I'm not sure how well grub can manage > this. Probably it can't, so you'd have to manage boot entries > manually. Yes, you are right. I can see all subvolumes under /path/to/subvolid_0 By the way grub2 can manage this setup correctly and generate the right menu entries without any problems. But - /boot is not in its own subvolume in this setup. I think this is the reason it works out of the box. Thank you for your explanations. I can see if I can make it work with /boot in its own subvolume. ~d -- 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: Snapshot rollback
Fajar A. Nugraha fajar.net> writes: > AFAIK you have three possible ways to use /boot on btrfs: > > (1) put /boot on subvolid=0, don't change the default subvolume. That > works, but all your snapshot/subvols will be visible under /boot. Some > people might not want that for estetic reason. Hi Fajar, I think I am doing just this, but my subvolumes are not visible under /boot. I have all my subvolumes set up like this: /path/to/subvolid_0/boot < a simple directory bind-mounted to / /path/to/subvolid_0/__active < my / subvolume /path/to/subvolid_0/__home < my /home subvolume > (3) put /boot on a subvolume, do not change the default subvolume, and > manage grub.cfg manually. This is what I currently do. Could you elaborate about this option pls., and if possible post your grub.cfg? I don't quite understand how it works. Though I am doing syslinux at the moment, I think the process is the same. thanks ~dima -- 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: Snapshot rollback
Fajar A. Nugraha fajar.net> writes: > A problem with that, though, if you decide to put /boot on btrfs as > well. Grub uses the default subvolume to determine paths (for kernel, > initrd, etc). A workaround is to manually create and manage your > grub.cfg (or create and use a manual-managed include file, like > custom-top.cfg, that gets parsed before the automatically created > entries). Oops, sorry, I was incorrect of course. Thanks Fajar. I do have /boot in my subvolid=0 because bootloaders can't read inside subvolumes (other than the default) as far as I understand. And I just bind /boot through fstab. -- 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: Snapshot rollback
Phillip Susi cfl.rr.com> writes: > I created a snapshot of my root subvol, then used btrfs-subvolume > set-default to make the snapshot the default subvol and rebooted. This > seems to have correctly gotten the system to boot from the snapshot > instead of the original subvol, but now /home ( @home subvol ) refuses > to mount claiming that /dev/sda1 is not a valid block device. What gives? Hello Phillip, It is hard to judge without seeing your fstab and bootloader config. Maybe your / was directly in subvolid=0 without creating a separate subvolume for it (like __active in Goffredo's reply)? In my very humble opinion, if you have your @home subvolume under subvolid=0 and then change the default subvolume, it just cannot access your @home any more. Personally I do not store anything in subvolid=0 directly and never bothered with 'set-default' option - just used a new subvolume/snapshot name - create a named snapshot - edit bootloader config to include the new rootflags=subvol= - reboot Here is a very good article that explains the working of subvolumes. I used it as reference a lot. http://www.funtoo.org/wiki/BTRFS_Fun#Using_snapshots_for_system_recovery_.28aka_Back_to_the_Future.29 ~dima -- 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 hangs after deleting bad file
Hello, I had a similar problem. Some files (2-3) got corrupted in my /home subvolume for no apparent reason. Trying to access the files gives kernel oops. Sometimes it freezes the machine, sometimes I am back to my console without any problems. Then I switched to the latest 3.1rc and freezes were gone (though I still had the kernel oops). (I did not try the repair program fearing that it would do more bad than good. After all, my / subvolume was fine and i still could mount /home) But to tackle the problems with corrupted files I had to create a new subvolume for /home, tranfer the files from the old one (minus the corrupted files) and delete the old subvolume. Though still btrfsck would give me errors trying to access some inode. But I could mount and use all my subvolumes with no problems. Then... I re-created btrfs with the latest btrfs-tools and installed the latest 3.1rc from the very beginning. So far, it is working fine and the situation with disk I/O has greatly improved. I think you may want to try to upgrade to the latest 3.1rc and at the very least you (hopefully) should not be getting hard freezes any more. best ~dima -- 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: unresolved ref root error
Thanks Liu Bo! Understood. ~ -- 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
unresolved ref root error
Hello, On a newly created filesystem with btrfs-progs-git-20111009 and the 3.1.0-rc8 kernel I am getting the following error when doing btrfsck after main OS installation fs tree 256 refs 2 unresolved ref root 256 dir 256 index 2 namelen 8 name __active error 600 found 4215058432 bytes used err is 1 total csum bytes: 3962760 total tree bytes: 157192192 total fs tree bytes: 146976768 btree space waste bytes: 45236856 file data blocks allocated: 4123439104 referenced 4056010752 Btrfs v0.19-35-g1b444cd-dirty 256 is the subvolume for / [root@yukikaze ~]# btrfs subvol list / ID 256 top level 5 path __active ID 257 top level 5 path __home Should I be concerned with this error? I saw a similar question here http://comments.gmane.org/gmane.comp.file-systems.btrfs/12455 but no hints were provided for the reason of the error. Any info is appreciated. thanks ~dima -- 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: Corrupt file in subvolume
I have upgraded to 3.1 rc8. I created a new subvolume for /home, copied the files there from the old subvolume and deleted the old subvolume. It looks like the space has been reclaimed fine. Though when doing btrfsck I am still getting the same error failed to find block number 150121762816 -- 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: Corrupt file in subvolume
Oh, I see. The fix is not in 3.0.x but on the master branch. I will need the latest 3.1 RC. I will try this. Thanks 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: Corrupt file in subvolume
f 2234 itemsize 51 extent refs 1 gen 33099 flags 2 tree block key (1215402 1 0) level 0 tree block backref root 257 (i.e. very early, about 4-5 seconds after I started checking) it gave me an error failed to find block number 150121762816 Unless I touch this file, the FS is fully functional. Yes, I can create a new subvolume of course, but as I mentioned before, there is a big chance that the corrupted one will not be deleted cleanly and my disk gets bloated even more with junk data I can do nothing about. thanks ~dima -- 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
Corrupt file in subvolume
ys_newstat+0x1a/0x40 Oct 10 10:38:03 yukikaze kernel: [34592.275601] [] ? sys_rt_sigaction+0x8d/0xc0 Oct 10 10:38:03 yukikaze kernel: [34592.275610] [] ? page_fault+0x25/0x30 Oct 10 10:38:03 yukikaze kernel: [34592.275617] [] system_call_fastpath+0x16/0x1b My question - is it possible to delete this rogue file somehow or repair it? I tried to delete the directory that contained it, but got the same Input/output error. Any help is appreciated. I need to mention that I did have the very same error about a couple of months ago with about 30 files getting corrupt this way in my /home. I had to create a new subvolume for /home (__home-new) and restore the missing files from backup. When I tried to delete the corrupted subvolume it gave me a bunch of kernel errors, but when I repeated the command, it completed ok. However, on reboot the space from this subvolume was not recovered. I tried to balance the subvolume after that but after a couple of hours I am getting only the note about 22 extents in my kernel.log Oct 10 11:03:22 yukikaze kernel: [36111.396313] btrfs: found 22 extents Oct 10 11:03:27 yukikaze kernel: [36116.922236] btrfs: found 22 extents Oct 10 11:03:33 yukikaze kernel: [36122.922488] btrfs: found 22 extents and no relocation messages. So I think it go stuck ( thanks ~dima --- archlinux Linux yukikaze 3.0.6-aya1 #3 SMP PREEMPT Sat Oct 8 19:01:41 JST 2011 x86_64 AMD Athlon(tm) II X4 635 Processor AuthenticAMD GNU/Linux the latest btrfs-tools -- 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
