cannot resize (grow) fs
Hello, I added disk to raid5 array on one of the backup hosts, running btrfs. So on /dev/md2 I have plenty of space now. However when I run btrfs filesystem resize max /dev/md2 I get Resize '/dev/md2' of 'max' ERROR: unable to resize '/dev/md2' The same result when I try resize +1g. strace gives me http://paste.pocoo.org/show/266523/ Any ideas why and how can I extend the filesystem to fill the whole volume? Thank you Lubos -- 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: [stable] Dirtiable inode bdi default != sb bdi btrfs
On Thu, Sep 23, 2010 at 09:40:14PM +0200, Jens Axboe wrote: > On 2010-09-23 21:38, Andrew Morton wrote: > > > > (Cc sta...@kernel.org) > > > > On Wed, 22 Sep 2010 21:54:30 -0300 > > Cesar Eduardo Barros wrote: > > > >> This started appearing for me on v2.6.36-rc5-49-gc79bd89; it did not > >> happen on v2.6.36-rc5-33-g1ce1e41, probably because it does not have > >> commit 692ebd17c2905313fff3c504c249c6a0faad16ec which introduces the > >> warning. > >> > >> [...] > >> device fsid 44d595920ddedfa-3ece6b56e80f689e devid 1 transid 22342 > >> /dev/mapper/vg_cesarbinspiro-lv_home > >> SELinux: initialized (dev dm-3, type btrfs), uses xattr > >> [ cut here ] > >> WARNING: at fs/fs-writeback.c:87 inode_to_bdi+0x62/0x6d() > >> Hardware name: Inspiron N4010 > >> Dirtiable inode bdi default != sb bdi btrfs > >> Modules linked in: ipv6 kvm_intel kvm uinput arc4 ecb > >> snd_hda_codec_intelhdmi snd_hda_codec_realtek iwlagn snd_hda_intel > >> iwlcore snd_hda_codec uvcvideo snd_hwdep mac80211 videodev snd_seq > >> snd_seq_device v4l1_compat snd_pcm atl1c v4l2_compat_ioctl32 btusb > >> cfg80211 snd_timer i2c_i801 bluetooth iTCO_wdt dell_wmi dell_laptop snd > >> pcspkr wmi dcdbas shpchp iTCO_vendor_support soundcore snd_page_alloc > >> rfkill joydev microcode btrfs zlib_deflate libcrc32c cryptd aes_x86_64 > >> aes_generic xts gf128mul dm_crypt usb_storage i915 drm_kms_helper drm > >> i2c_algo_bit i2c_core video output [last unloaded: scsi_wait_scan] > >> Pid: 1073, comm: find Not tainted 2.6.36-rc5+ #8 > >> Call Trace: > >> [] warn_slowpath_common+0x85/0x9d > >> [] warn_slowpath_fmt+0x46/0x48 > >> [] inode_to_bdi+0x62/0x6d > >> [] __mark_inode_dirty+0xd0/0x177 > >> [] touch_atime+0x107/0x12a > >> [] ? filldir+0x0/0xd0 > >> [] vfs_readdir+0x8d/0xb4 > >> [] sys_getdents+0x81/0xd1 > >> [] system_call_fastpath+0x16/0x1b > > > > Thanks. 692ebd17c2905313fff3c504c249c6a0faad16ec had a cc:stable in > > the changelog. I'd suggest it not be merged into -stable until this > > regression is sorted out! > > It was just added, I'm discussing this with Chris on irc as I type this. > But yes, lets not replace a regression with a new regression :-). So > Greg, please hold off on these for a little while. Ok, so which ones should I take out of the -stable tree? Just this one: 692ebd17c2905313fff3c504c249c6a0faad16ec or it and something else? thanks, greg k-h -- 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
Any btrfsck to try out? [was: "parent transid verify failed", continued]
On Thu, Sep 23, 2010 at 08:24, Francis Galiegue wrote: [...] > > For this particular filesystem, which contains qemu-kvm disk images in > raw mode with caching mode set to "writeback", the symptoms is that: > > * in 2.6.34 and lower, I could mount the filesystem, with the "parent > transid verify failed" message appearing once; > * with 2.6.35+ and upper, however, not anymore: I mount it and the > same "parent transid very failed" message now floods dmesg, and I > cannot kill -9 any program trying to access that filesystem. > [...] Another thing: as I can afford to recreate the hosed filesystem if need be, I'm also ready to try any offline (of course) repairing btrfsck on this filesystem and see if I can mount it again safely. Any btrfs-progs tree that I might try out? I have the possibility to boot from a USB key with a sufficiently recent kernel and test that, and attempt to mount the fs again... -- Francis Galiegue, fgalie...@gmail.com "It seems obvious [...] that at least some 'business intelligence' tools invest so much intelligence on the business side that they have nothing left for generating SQL queries" (Stéphane Faroult, in "The Art of SQL", ISBN 0-596-00894-5) -- 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: Dirtiable inode bdi default != sb bdi btrfs
On 2010-09-23 21:38, Andrew Morton wrote: > > (Cc sta...@kernel.org) > > On Wed, 22 Sep 2010 21:54:30 -0300 > Cesar Eduardo Barros wrote: > >> This started appearing for me on v2.6.36-rc5-49-gc79bd89; it did not >> happen on v2.6.36-rc5-33-g1ce1e41, probably because it does not have >> commit 692ebd17c2905313fff3c504c249c6a0faad16ec which introduces the >> warning. >> >> [...] >> device fsid 44d595920ddedfa-3ece6b56e80f689e devid 1 transid 22342 >> /dev/mapper/vg_cesarbinspiro-lv_home >> SELinux: initialized (dev dm-3, type btrfs), uses xattr >> [ cut here ] >> WARNING: at fs/fs-writeback.c:87 inode_to_bdi+0x62/0x6d() >> Hardware name: Inspiron N4010 >> Dirtiable inode bdi default != sb bdi btrfs >> Modules linked in: ipv6 kvm_intel kvm uinput arc4 ecb >> snd_hda_codec_intelhdmi snd_hda_codec_realtek iwlagn snd_hda_intel >> iwlcore snd_hda_codec uvcvideo snd_hwdep mac80211 videodev snd_seq >> snd_seq_device v4l1_compat snd_pcm atl1c v4l2_compat_ioctl32 btusb >> cfg80211 snd_timer i2c_i801 bluetooth iTCO_wdt dell_wmi dell_laptop snd >> pcspkr wmi dcdbas shpchp iTCO_vendor_support soundcore snd_page_alloc >> rfkill joydev microcode btrfs zlib_deflate libcrc32c cryptd aes_x86_64 >> aes_generic xts gf128mul dm_crypt usb_storage i915 drm_kms_helper drm >> i2c_algo_bit i2c_core video output [last unloaded: scsi_wait_scan] >> Pid: 1073, comm: find Not tainted 2.6.36-rc5+ #8 >> Call Trace: >> [] warn_slowpath_common+0x85/0x9d >> [] warn_slowpath_fmt+0x46/0x48 >> [] inode_to_bdi+0x62/0x6d >> [] __mark_inode_dirty+0xd0/0x177 >> [] touch_atime+0x107/0x12a >> [] ? filldir+0x0/0xd0 >> [] vfs_readdir+0x8d/0xb4 >> [] sys_getdents+0x81/0xd1 >> [] system_call_fastpath+0x16/0x1b > > Thanks. 692ebd17c2905313fff3c504c249c6a0faad16ec had a cc:stable in > the changelog. I'd suggest it not be merged into -stable until this > regression is sorted out! It was just added, I'm discussing this with Chris on irc as I type this. But yes, lets not replace a regression with a new regression :-). So Greg, please hold off on these for a little while. -- Jens Axboe -- 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: Dirtiable inode bdi default != sb bdi btrfs
On Thu, Sep 23, 2010 at 12:38:49PM -0700, Andrew Morton wrote: > > (Cc sta...@kernel.org) > > On Wed, 22 Sep 2010 21:54:30 -0300 > Cesar Eduardo Barros wrote: > > > This started appearing for me on v2.6.36-rc5-49-gc79bd89; it did not > > happen on v2.6.36-rc5-33-g1ce1e41, probably because it does not have > > commit 692ebd17c2905313fff3c504c249c6a0faad16ec which introduces the > > warning. The problem is that btrfs isn't setting the inode bdi on the directory inode. I'm digging now to see if this code is right for blockdevice/special inodes as well. -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: Dirtiable inode bdi default != sb bdi btrfs
(Cc sta...@kernel.org) On Wed, 22 Sep 2010 21:54:30 -0300 Cesar Eduardo Barros wrote: > This started appearing for me on v2.6.36-rc5-49-gc79bd89; it did not > happen on v2.6.36-rc5-33-g1ce1e41, probably because it does not have > commit 692ebd17c2905313fff3c504c249c6a0faad16ec which introduces the > warning. > > [...] > device fsid 44d595920ddedfa-3ece6b56e80f689e devid 1 transid 22342 > /dev/mapper/vg_cesarbinspiro-lv_home > SELinux: initialized (dev dm-3, type btrfs), uses xattr > [ cut here ] > WARNING: at fs/fs-writeback.c:87 inode_to_bdi+0x62/0x6d() > Hardware name: Inspiron N4010 > Dirtiable inode bdi default != sb bdi btrfs > Modules linked in: ipv6 kvm_intel kvm uinput arc4 ecb > snd_hda_codec_intelhdmi snd_hda_codec_realtek iwlagn snd_hda_intel > iwlcore snd_hda_codec uvcvideo snd_hwdep mac80211 videodev snd_seq > snd_seq_device v4l1_compat snd_pcm atl1c v4l2_compat_ioctl32 btusb > cfg80211 snd_timer i2c_i801 bluetooth iTCO_wdt dell_wmi dell_laptop snd > pcspkr wmi dcdbas shpchp iTCO_vendor_support soundcore snd_page_alloc > rfkill joydev microcode btrfs zlib_deflate libcrc32c cryptd aes_x86_64 > aes_generic xts gf128mul dm_crypt usb_storage i915 drm_kms_helper drm > i2c_algo_bit i2c_core video output [last unloaded: scsi_wait_scan] > Pid: 1073, comm: find Not tainted 2.6.36-rc5+ #8 > Call Trace: > [] warn_slowpath_common+0x85/0x9d > [] warn_slowpath_fmt+0x46/0x48 > [] inode_to_bdi+0x62/0x6d > [] __mark_inode_dirty+0xd0/0x177 > [] touch_atime+0x107/0x12a > [] ? filldir+0x0/0xd0 > [] vfs_readdir+0x8d/0xb4 > [] sys_getdents+0x81/0xd1 > [] system_call_fastpath+0x16/0x1b Thanks. 692ebd17c2905313fff3c504c249c6a0faad16ec had a cc:stable in the changelog. I'd suggest it not be merged into -stable until this regression is sorted out! > > ... > > These are only the first two; they keep happening, with several > different processes (it is not only find), but always btrfs (I have / > and /home on btrfs and /boot on ext4). In case it makes any difference, > /dev seems to be on devtmpfs, and everything uses relatime. > > There is also the following one which is not on vfs_readdir: > > [ cut here ] > WARNING: at fs/fs-writeback.c:87 inode_to_bdi+0x62/0x6d() > Hardware name: Inspiron N4010 > Dirtiable inode bdi default != sb bdi btrfs > Modules linked in: ipv6 kvm_intel kvm uinput arc4 ecb > snd_hda_codec_intelhdmi snd_hda_codec_realtek iwlagn snd_hda_intel > iwlcore snd_hda_codec uvcvideo snd_hwdep mac80211 videodev snd_seq > snd_seq_device v4l1_compat snd_pcm atl1c v4l2_compat_ioctl32 btusb > cfg80211 snd_timer i2c_i801 bluetooth iTCO_wdt dell_wmi dell_laptop snd > pcspkr wmi dcdbas shpchp iTCO_vendor_support soundcore snd_page_alloc > rfkill joydev microcode btrfs zlib_deflate libcrc32c cryptd aes_x86_64 > aes_generic xts gf128mul dm_crypt usb_storage i915 drm_kms_helper drm > i2c_algo_bit i2c_core video output [last unloaded: scsi_wait_scan] > Pid: 1104, comm: mkdir Tainted: GW 2.6.36-rc5+ #8 > Call Trace: > [] warn_slowpath_common+0x85/0x9d > [] warn_slowpath_fmt+0x46/0x48 > [] inode_to_bdi+0x62/0x6d > [] __mark_inode_dirty+0xd0/0x177 > [] btrfs_setattr+0x210/0x23a [btrfs] > [] notify_change+0x1a2/0x29d > [] sys_fchmod+0xac/0xfd > [] ? sys_newfstat+0x2e/0x39 > [] system_call_fastpath+0x16/0x1b -- 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, NFS (v3) and ESTALE
I wonder how difficult it would be to use GFS storage allocation, so the right way to cluster btrfs would be at the block device level instead of file system level. Like the way btrfs can coexist in ext4 partition, but coexisting with GFS. On Thu, Sep 23, 2010 at 6:02 AM, David Flynn wrote: > Dear all; > > On a cluster of ~35 machines used for batch processing, which all mount > via NFS (v3) a BTRFS export, I am experiencing -- 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, NFS (v3) and ESTALE
Hi David, On 23 September 2010 12:02, David Flynn wrote: > Dear all; > > On a cluster of ~35 machines used for batch processing, which all mount > via NFS (v3) a BTRFS export, I am experiencing issues that are causing > NFS clients to occasionally produce Stale NFS handle errors on accessing > this file system. I would be interested to know if this is possibly > related to use of BTRFS, or is mere coincidence. > > Background: > - The NFS server is running 2.6.33, with a btrfs file system created > under the same kernel. > > - The file system is mounted as: > /dev/md2 /work btrfs rw,noatime,nodiratime 0 0 > > - The file system is exported as: > /work (rw,wdelay,root_squash,no_subtree_check) > > - Clients are mostly 2.6.35, however, problems have also been > seen with 2.6.32. > > - Clients mount (from /proc/mounts) > vc-fs0:/work /work nfs > rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=172.29.146.16,mountvers=3,mountport=51102,mountproto=udp,addr=172.29.146.16 > 0 0 > > The problem manifests itself when issuing a job to the cluster, of ~120 > tasks on 30 nodes. We will occasionally find that a machine reports > NFS stale filehandle errors when trying to stat a directory. The > directory will not have been deleted during the lifetime of the job, > however some (eg 30) sub-directories will have been created. > > The erros are Usually seen from a machine that has not done any work. > > For example: > > (2.6.35:) > vcfe0:~$ ls -l /work >/dev/null > --launch job (doesn't do anything on vcfe, uses different nodes)-- > ... time passes (unknown how long) ... > > vcfe0:~$ ls -l /work >/dev/null > ls: cannot access /work/marta-cip-test: Stale NFS file handle > ls: cannot access /work/andrea-test-ais: Stale NFS file handle > > (2.6.35:) > vc-r210-0:~$ ls -l /work >/dev/null > vc-r210-0:~$ > > (2.6.32:) > b36048:~$ ls -l /work/ >/dev/null > ls: cannot access /work/marta-cip-test: Stale NFS file handle > ls: cannot access /work/andrea-test-ais: Stale NFS file handle > > Two separate machines are seeing the same stale file handles. b36048 > hadn't even touched /work for some considerable time before doing that > ls. > > performing `touch /work/andrea-test-ais' on the client will allow the > client machine to stat the directory again, however, doing it on the > file server does not. > > performing `echo 2 > /proc/sys/vm/drop_caches' on the client will > sometimes solve the problem for that client [but not always]. > > I've not yet found a reliable way to reproduce the problem, other than > running large jobs (we aren't running small ones at the moment, so can't > say if it is related to size) > > I would be interested to know if anyone believes this may be related to > the use of btrfs, (or even a configuration / nfs cache coherency problem). > > Some extra anecdotal evidence: > I don't recall this being an issue before we upgraded all the compute > nodes to 2.6.35. Previously they used 2.6.33, but an upgrade was > forced due to an nfs bug under high write loads. However, it may be > that the nature of the jobs that we are running now has changed > slightly too. I was experiencing a similar pattern of ESTALE issues with NFS with 2.6.33 (IIRC) and cached data on ext4, and could reproduce it from time to time performing kernel rebuilds over NFS. I've CC'd Trond on the full email to see if it rings a bell. The best outcome may be if we write a micro-reproducer which exploits this race using cached data. Thanks, Daniel -- Daniel J Blueman -- 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, NFS (v3) and ESTALE
Dear all; On a cluster of ~35 machines used for batch processing, which all mount via NFS (v3) a BTRFS export, I am experiencing issues that are causing NFS clients to occasionally produce Stale NFS handle errors on accessing this file system. I would be interested to know if this is possibly related to use of BTRFS, or is mere coincidence. Background: - The NFS server is running 2.6.33, with a btrfs file system created under the same kernel. - The file system is mounted as: /dev/md2 /work btrfs rw,noatime,nodiratime 0 0 - The file system is exported as: /work (rw,wdelay,root_squash,no_subtree_check) - Clients are mostly 2.6.35, however, problems have also been seen with 2.6.32. - Clients mount (from /proc/mounts) vc-fs0:/work /work nfs rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=172.29.146.16,mountvers=3,mountport=51102,mountproto=udp,addr=172.29.146.16 0 0 The problem manifests itself when issuing a job to the cluster, of ~120 tasks on 30 nodes. We will occasionally find that a machine reports NFS stale filehandle errors when trying to stat a directory. The directory will not have been deleted during the lifetime of the job, however some (eg 30) sub-directories will have been created. The erros are Usually seen from a machine that has not done any work. For example: (2.6.35:) vcfe0:~$ ls -l /work >/dev/null --launch job (doesn't do anything on vcfe, uses different nodes)-- ... time passes (unknown how long) ... vcfe0:~$ ls -l /work >/dev/null ls: cannot access /work/marta-cip-test: Stale NFS file handle ls: cannot access /work/andrea-test-ais: Stale NFS file handle (2.6.35:) vc-r210-0:~$ ls -l /work >/dev/null vc-r210-0:~$ (2.6.32:) b36048:~$ ls -l /work/ >/dev/null ls: cannot access /work/marta-cip-test: Stale NFS file handle ls: cannot access /work/andrea-test-ais: Stale NFS file handle Two separate machines are seeing the same stale file handles. b36048 hadn't even touched /work for some considerable time before doing that ls. performing `touch /work/andrea-test-ais' on the client will allow the client machine to stat the directory again, however, doing it on the file server does not. performing `echo 2 > /proc/sys/vm/drop_caches' on the client will sometimes solve the problem for that client [but not always]. I've not yet found a reliable way to reproduce the problem, other than running large jobs (we aren't running small ones at the moment, so can't say if it is related to size) I would be interested to know if anyone believes this may be related to the use of btrfs, (or even a configuration / nfs cache coherency problem). Some extra anecdotal evidence: I don't recall this being an issue before we upgraded all the compute nodes to 2.6.35. Previously they used 2.6.33, but an upgrade was forced due to an nfs bug under high write loads. However, it may be that the nature of the jobs that we are running now has changed slightly too. Kind regards, ..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
