Online resize vs ENOSPC

Online resize vs ENOSPC

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 1506 bytes --]

   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!                          

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Online resize vs ENOSPC

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 1332 bytes --]

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. ---            

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Online resize vs ENOSPC

[Chris Mason]

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