ENOSPC on almost empty FS

ENOSPC on almost empty FS

[Stephane CHAZELAS]

Hiya,

trying to restore a FS from a backup (tgz) on a freshly made
btrfs this morning, I got ENOSPCs after about 100MB out of 4GB
have been extracted. strace indicates that the ENOSPC are upon
the open(O_WRONLY).

Restoring with:

mkfs.btrfs /dev/mapper/VG_USB-root
mount -o compress-force,ssd $_ /mnt
cd /mnt
pv ~/backup.tgz | gunzip | sudo bsdtar -xpSf - --numeric-owner


That's on a LVM LV with the PV on a USB key.

If I supspend the job and resume it, then the ENOSPCs go away.

The only way I could restore the backup was via rate limiting
the untar:

zcat ~/backup.tgz | pv -L 3000000 | sudo bsdtar -xpSf - --numeric-owner

That 3MB/s wasn't even enough, as 3 files triggered a ENOSPC,
but I did untar them separately afterwards.

That's with debian's 3.0.0-1 amd64 kernel.

Is that expected behavior due to the way allocation works in
btrfs?

-- 
Stephane

Re: ENOSPC on almost empty FS

[Mitch Harder]

On Tue, Nov 1, 2011 at 3:36 AM, Stephane CHAZELAS
<stephane_chazelas@yahoo.fr> wrote:
> Hiya,
>
> trying to restore a FS from a backup (tgz) on a freshly made
> btrfs this morning, I got ENOSPCs after about 100MB out of 4GB
> have been extracted. strace indicates that the ENOSPC are upon
> the open(O_WRONLY).
>
> Restoring with:
>
> mkfs.btrfs /dev/mapper/VG_USB-root
> mount -o compress-force,ssd $_ /mnt
> cd /mnt
> pv ~/backup.tgz | gunzip | sudo bsdtar -xpSf - --numeric-owner
>
>
> That's on a LVM LV with the PV on a USB key.
>
> If I supspend the job and resume it, then the ENOSPCs go away.
>
> The only way I could restore the backup was via rate limiting
> the untar:
>
> zcat ~/backup.tgz | pv -L 3000000 | sudo bsdtar -xpSf - --numeric-owner
>
> That 3MB/s wasn't even enough, as 3 files triggered a ENOSPC,
> but I did untar them separately afterwards.
>
> That's with debian's 3.0.0-1 amd64 kernel.
>
> Is that expected behavior due to the way allocation works in
> btrfs?
>

I have also run into similar behavior while restoring a volume with tar.

I believe this is fixed by one of Josef's recent patches, but it might
be one of the patches queued for 3.2.