After an online resize, the filesystem reports its new size, but
still runs out of space at the old size:
Mar 9 08:12:59 vlad kernel: no space left, need 4096, 380928 delalloc bytes,
51509866496 bytes_used, 0 bytes_reserved, 0 bytes_pinned, 0 bytes_readonly, 0
may use51510247424 total
[...]
Mar 9 08:14:21 vlad kernel: no space left, need 4096, 0 delalloc bytes,
51510247424 bytes_used, 0 bytes_reserved, 0 bytes_pinned, 0 bytes_readonly, 0
may use51510247424 total
hrm@vlad:~ $ df -h
Filesystem Size Used Avail Use% Mounted on
[...]
/dev/mapper/media-scratch
70G 48G 23G 68% /media/vlad/video/video
This was online resized from 50G to 70G, using:
$ sudo lvresize media/scratch -L 70G
$ sudo btrfsctl -r 70G /media/vlad/video/video
Version numbers:
$ btrfsctl
[...]
Btrfs v0.18-ge3b0f66
$ uname -a
Linux vlad 2.6.29-rc7 #1 Fri Mar 6 23:32:13 GMT 2009 x86_64 GNU/Linux
Unmounting and remounting the filesystem seems to make the new
space available for use again.
This is the second time I''ve had this happen to me now, so it seems
to be more-or-less reproducible, although I haven''t deliberately tried
to trigger the behaviour yet.
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
--- Klytus! Are your men on the right pills? Maybe you should ---
execute their trainer!
On Mon, Mar 09, 2009 at 10:31:41AM +0000, Hugo Mills wrote:> After an online resize, the filesystem reports its new size, but > still runs out of space at the old size:[...]> Unmounting and remounting the filesystem seems to make the new > space available for use again. > > This is the second time I''ve had this happen to me now, so it seems > to be more-or-less reproducible, although I haven''t deliberately tried > to trigger the behaviour yet.Just to confirm, I can indeed reproduce it trivially: $ sudo lvcreate scratch -n testresize -L 5G $ sudo mkfs.btrfs /dev/scratch/testresize $ sudo mount /dev/scratch/testresize /mnt $ sudo chmod ug+w /mnt $ sudo chown hrm. /mnt $ cd /mnt $ dd if=/dev/zero of=foo.txt bs=1M count=4096 $ sudo lvextend scratch/testresize -L 9G $ sudo btrfsctl -r 9G /mnt $ dd if=/dev/zero of=foo2.txt bs=1M count=4096 and I get an out-of-space error within a few hundred blocks. $ cd .. $ sudo umount /mnt $ sudo mount /dev/scratch/testresize /mnt $ cd /mnt $ dd if=/dev/zero of=foo2.txt bs=1M count=4096 and then I can write the full 4G of data. 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 --- There are three mistaiks in this sentance. ---
On Mon, 2009-03-09 at 14:35 +0000, Hugo Mills wrote:> On Mon, Mar 09, 2009 at 10:31:41AM +0000, Hugo Mills wrote: > > After an online resize, the filesystem reports its new size, but > > still runs out of space at the old size: > [...] > > Unmounting and remounting the filesystem seems to make the new > > space available for use again. > > > > This is the second time I''ve had this happen to me now, so it seems > > to be more-or-less reproducible, although I haven''t deliberately tried > > to trigger the behaviour yet. > > Just to confirm, I can indeed reproduce it trivially: >Ok, thanks for tracking this down. I see the bug and will send out a fix shortly for you to try. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html