* Issues when volume is full
@ 2010-03-04 20:58 Robert LeBlanc
2010-03-04 21:10 ` Josef Bacik
0 siblings, 1 reply; 4+ messages in thread
From: Robert LeBlanc @ 2010-03-04 20:58 UTC (permalink / raw)
To: linux-btrfs
I've been using btrfs as a spool space on our back-up server to get
familiar with it and things work fine until the volume fills up. Our
backup software (bacula) usually spools until the volume is full, then
despools and respools, etc. With btrfs, it fills up and bacula thinks
there is still space so it keeps trying and then finally errors out. I
thought this was a problem because I was using compression, but I've
repeated the problem without compression. Doing some tests, this is
what I've found:
lsddomainsd:/spool# dd if=3D/dev/zero of=3Djunk bs=3D1024000
dd: writing `junk': No space left on device
522163+0 records in
522162+0 records out
534693888000 bytes (535 GB) copied, 6026.85 s, 88.7 MB/s
lsddomainsd:/spool# ls
junk
lsddomainsd:/spool# df -h
=46ilesystem=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Size=A0 Used Avail Use% M=
ounted on
/dev/mapper/lsddomain-root
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 6.5G=A0=
3.5G=A0 2.7G=A0 58% /
tmpfs=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2.0G=A0=A0=A0=A0 =
0=A0 2.0G=A0=A0 0% /lib/init/rw
udev=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 10M=A0 172K=A0=
9.9M=A0=A0 2% /dev
tmpfs=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2.0G=A0=A0=A0=A0 =
0=A0 2.0G=A0=A0 0% /dev/shm
/dev/sda1=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 228M=A0=A0 92M=A0 124M=A0=
43% /boot
/dev/mapper/lsddomain-home
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 4.6G=A0=
138M=A0 4.5G=A0=A0 3% /home
192.168.58.2:/backup/bacula
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2.5T=A0=
996G=A0 1.5T=A0 40% /backup
/dev/mapper/spool=A0=A0=A0=A0 500G=A0 499G=A0 1.6G 100% /spool
lsddomainsd:/spool# dd if=3D/dev/zero of=3Djunk2 bs=3D1024000
dd: writing `junk2': No space left on device
1+0 records in
0+0 records out
0 bytes (0 B) copied, 0.0704083 s, 0.0 kB/s
lsddomainsd:/spool# dd if=3D/dev/zero of=3Djunk3 bs=3D1024000
dd: writing `junk3': No space left on device
1+0 records in
0+0 records out
0 bytes (0 B) copied, 0.108706 s, 0.0 kB/s
lsddomainsd:/spool# ls -lh
total 498G
-rw-r--r-- 1 root root 498G 2010-03-04 09:54 junk
-rw-r--r-- 1 root root=A0=A0=A0 0 2010-03-04 13:45 junk2
-rw-r--r-- 1 root root=A0=A0=A0 0 2010-03-04 13:45 junk3
lsddomainsd:/spool#
So even though the volume is full it shows space left. Is this
supposed to happen? I don't remember seeing any space left on other
file systems and I've filled quite a few.
Thanks,
Robert LeBlanc
Life Sciences & Undergraduate Education Computer Support
Brigham Young University
--
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Issues when volume is full
2010-03-04 20:58 Issues when volume is full Robert LeBlanc
@ 2010-03-04 21:10 ` Josef Bacik
2010-03-04 21:20 ` Robert LeBlanc
2010-03-04 21:51 ` Df [Was: Re: Issues when volume is full] James Cloos
0 siblings, 2 replies; 4+ messages in thread
From: Josef Bacik @ 2010-03-04 21:10 UTC (permalink / raw)
To: Robert LeBlanc; +Cc: linux-btrfs
On Thu, Mar 04, 2010 at 01:58:22PM -0700, Robert LeBlanc wrote:
> I've been using btrfs as a spool space on our back-up server to get
> familiar with it and things work fine until the volume fills up. Our
> backup software (bacula) usually spools until the volume is full, the=
n
> despools and respools, etc. With btrfs, it fills up and bacula thinks
> there is still space so it keeps trying and then finally errors out. =
I
> thought this was a problem because I was using compression, but I've
> repeated the problem without compression. Doing some tests, this is
> what I've found:
>=20
> lsddomainsd:/spool# dd if=3D/dev/zero of=3Djunk bs=3D1024000
> dd: writing `junk': No space left on device
> 522163+0 records in
> 522162+0 records out
> 534693888000 bytes (535 GB) copied, 6026.85 s, 88.7 MB/s
> lsddomainsd:/spool# ls
> junk
> lsddomainsd:/spool# df -h
> Filesystem=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Size=A0 Used Avail Use% M=
ounted on
> /dev/mapper/lsddomain-root
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 6.5G=A0=
3.5G=A0 2.7G=A0 58% /
> tmpfs=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2.0G=A0=A0=A0=A0=
0=A0 2.0G=A0=A0 0% /lib/init/rw
> udev=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 10M=A0 172=
K=A0 9.9M=A0=A0 2% /dev
> tmpfs=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2.0G=A0=A0=A0=A0=
0=A0 2.0G=A0=A0 0% /dev/shm
> /dev/sda1=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 228M=A0=A0 92M=A0 124M=A0=
43% /boot
> /dev/mapper/lsddomain-home
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 4.6G=A0=
138M=A0 4.5G=A0=A0 3% /home
> 192.168.58.2:/backup/bacula
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2.5T=A0=
996G=A0 1.5T=A0 40% /backup
> /dev/mapper/spool=A0=A0=A0=A0 500G=A0 499G=A0 1.6G 100% /spool
> lsddomainsd:/spool# dd if=3D/dev/zero of=3Djunk2 bs=3D1024000
> dd: writing `junk2': No space left on device
> 1+0 records in
> 0+0 records out
> 0 bytes (0 B) copied, 0.0704083 s, 0.0 kB/s
> lsddomainsd:/spool# dd if=3D/dev/zero of=3Djunk3 bs=3D1024000
> dd: writing `junk3': No space left on device
> 1+0 records in
> 0+0 records out
> 0 bytes (0 B) copied, 0.108706 s, 0.0 kB/s
> lsddomainsd:/spool# ls -lh
> total 498G
> -rw-r--r-- 1 root root 498G 2010-03-04 09:54 junk
> -rw-r--r-- 1 root root=A0=A0=A0 0 2010-03-04 13:45 junk2
> -rw-r--r-- 1 root root=A0=A0=A0 0 2010-03-04 13:45 junk3
> lsddomainsd:/spool#
>=20
> So even though the volume is full it shows space left. Is this
> supposed to happen? I don't remember seeing any space left on other
> file systems and I've filled quite a few.
>=20
Yeah this is an unfortunate side-affect of how we currently do df. We =
plan on
changing it, but currently it just shows data used in the used column, =
so the
1.6G will be whats been reserved for metadata space. IIRC the consensu=
s was to
count the used amount from all spaces, and then just add the free unall=
ocated
space to that, but it will still likely end up with "Avail" having what=
is free
for metadata space, but not actually able to be used as data. Thanks,
Josef
--
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Issues when volume is full
2010-03-04 21:10 ` Josef Bacik
@ 2010-03-04 21:20 ` Robert LeBlanc
2010-03-04 21:51 ` Df [Was: Re: Issues when volume is full] James Cloos
1 sibling, 0 replies; 4+ messages in thread
From: Robert LeBlanc @ 2010-03-04 21:20 UTC (permalink / raw)
To: Josef Bacik; +Cc: linux-btrfs
On Thu, Mar 4, 2010 at 2:10 PM, Josef Bacik <josef@redhat.com> wrote:
> On Thu, Mar 04, 2010 at 01:58:22PM -0700, Robert LeBlanc wrote:
>> I've been using btrfs as a spool space on our back-up server to get
>> familiar with it and things work fine until the volume fills up. Our
>> backup software (bacula) usually spools until the volume is full, th=
en
>> despools and respools, etc. With btrfs, it fills up and bacula think=
s
>> there is still space so it keeps trying and then finally errors out.=
I
>> thought this was a problem because I was using compression, but I've
>> repeated the problem without compression. Doing some tests, this is
>> what I've found:
>>
>> lsddomainsd:/spool# dd if=3D/dev/zero of=3Djunk bs=3D1024000
>> dd: writing `junk': No space left on device
>> 522163+0 records in
>> 522162+0 records out
>> 534693888000 bytes (535 GB) copied, 6026.85 s, 88.7 MB/s
>> lsddomainsd:/spool# ls
>> junk
>> lsddomainsd:/spool# df -h
>> Filesystem=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Size=A0 Used Avail Use% =
Mounted on
>> /dev/mapper/lsddomain-root
>> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 6.5G=
=A0 3.5G=A0 2.7G=A0 58% /
>> tmpfs=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2.0G=A0=A0=A0=A0=
0=A0 2.0G=A0=A0 0% /lib/init/rw
>> udev=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 10M=A0 17=
2K=A0 9.9M=A0=A0 2% /dev
>> tmpfs=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2.0G=A0=A0=A0=A0=
0=A0 2.0G=A0=A0 0% /dev/shm
>> /dev/sda1=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 228M=A0=A0 92M=A0 124M=
=A0 43% /boot
>> /dev/mapper/lsddomain-home
>> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 4.6G=
=A0 138M=A0 4.5G=A0=A0 3% /home
>> 192.168.58.2:/backup/bacula
>> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2.5T=
=A0 996G=A0 1.5T=A0 40% /backup
>> /dev/mapper/spool=A0=A0=A0=A0 500G=A0 499G=A0 1.6G 100% /spool
>> lsddomainsd:/spool# dd if=3D/dev/zero of=3Djunk2 bs=3D1024000
>> dd: writing `junk2': No space left on device
>> 1+0 records in
>> 0+0 records out
>> 0 bytes (0 B) copied, 0.0704083 s, 0.0 kB/s
>> lsddomainsd:/spool# dd if=3D/dev/zero of=3Djunk3 bs=3D1024000
>> dd: writing `junk3': No space left on device
>> 1+0 records in
>> 0+0 records out
>> 0 bytes (0 B) copied, 0.108706 s, 0.0 kB/s
>> lsddomainsd:/spool# ls -lh
>> total 498G
>> -rw-r--r-- 1 root root 498G 2010-03-04 09:54 junk
>> -rw-r--r-- 1 root root=A0=A0=A0 0 2010-03-04 13:45 junk2
>> -rw-r--r-- 1 root root=A0=A0=A0 0 2010-03-04 13:45 junk3
>> lsddomainsd:/spool#
>>
>> So even though the volume is full it shows space left. Is this
>> supposed to happen? I don't remember seeing any space left on other
>> file systems and I've filled quite a few.
>>
>
> Yeah this is an unfortunate side-affect of how we currently do df. =A0=
We plan on
> changing it, but currently it just shows data used in the used column=
, so the
> 1.6G will be whats been reserved for metadata space. =A0IIRC the cons=
ensus was to
> count the used amount from all spaces, and then just add the free una=
llocated
> space to that, but it will still likely end up with "Avail" having wh=
at is free
> for metadata space, but not actually able to be used as data. =A0Than=
ks,
>
> Josef
>
So is it possible to prevent the creation of metadata if there is no
data blocks left. I wonder if that would solve this issue. Maybe if
Bacula sees it can't write a file at all, it then goes into
despooling. I wonder if other programs (cp, rsync, etc) will run into
the same problem when the volume is full. I know it's a corner case,
so I'm not going to press the issue when btrfs is not close to stable.
Just an issue I came across and thought I'd get some additional info
about.
Robert LeBlanc
Life Sciences & Undergraduate Education Computer Support
Brigham Young University
--
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Df [Was: Re: Issues when volume is full]
2010-03-04 21:10 ` Josef Bacik
2010-03-04 21:20 ` Robert LeBlanc
@ 2010-03-04 21:51 ` James Cloos
1 sibling, 0 replies; 4+ messages in thread
From: James Cloos @ 2010-03-04 21:51 UTC (permalink / raw)
To: linux-btrfs; +Cc: Josef Bacik, Robert LeBlanc
>>>>> "J" == Josef Bacik <josef@redhat.com> writes:
J> Yeah this is an unfortunate side-affect of how we currently do df.
Speaking of that, it would be cool were df -i to be enabled. Fs's like
xfs, AIUI, which have fully dynamic inode allocation just use the number
of blocks as the max possible number of inodes. Reporting that and
iused would be helpful.
-JimC
--
James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2010-03-04 21:51 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-03-04 20:58 Issues when volume is full Robert LeBlanc
2010-03-04 21:10 ` Josef Bacik
2010-03-04 21:20 ` Robert LeBlanc
2010-03-04 21:51 ` Df [Was: Re: Issues when volume is full] James Cloos
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox