* no space left on device.
@ 2012-11-01 13:35 Kenneth Johansson
2012-11-02 15:54 ` Kyle Gates
0 siblings, 1 reply; 45+ messages in thread
From: Kenneth Johansson @ 2012-11-01 13:35 UTC (permalink / raw)
To: linux-btrfs
So I have ended up in a state where I can't delete files with rm.
the error I get is no space on device. however I'm not even close to empty.
/dev/sdb1 38G 27G 9.5G 75%
there is about 800k files/dirs in this filesystem
extra strange is that I can in another directory create and delete files.
So I tried pretty much all I could google my way to but problem
persisted. So I decided to do a backup and a format. But when the backup
was done I tried one more time and now it was possible to delete the
directory and all content?
using the 3.5 kernel in ubuntu 12.10. Is this a known issue ? is it
fixed in later kernels?
fsck /btrfs scrub and kernel log. nothing indicate any problem of any kind.
^ permalink raw reply [flat|nested] 45+ messages in thread
* RE: no space left on device.
2012-11-01 13:35 no space left on device Kenneth Johansson
@ 2012-11-02 15:54 ` Kyle Gates
2012-11-02 15:59 ` Hugo Mills
2012-11-06 13:23 ` Kenneth Johansson
0 siblings, 2 replies; 45+ messages in thread
From: Kyle Gates @ 2012-11-02 15:54 UTC (permalink / raw)
To: Kenneth Johansson, linux-btrfs
> So I have ended up in a state where I can't delete files with rm.
>
> the error I get is no space on device. however I'm not even close to empty.
> /dev/sdb1 38G 27G 9.5G 75%
> there is about 800k files/dirs in this filesystem
>
> extra strange is that I can in another directory create and delete files.
>
> So I tried pretty much all I could google my way to but problem
> persisted. So I decided to do a backup and a format. But when the backup
> was done I tried one more time and now it was possible to delete the
> directory and all content?
>
> using the 3.5 kernel in ubuntu 12.10. Is this a known issue ? is it
> fixed in later kernels?
>
> fsck /btrfs scrub and kernel log. nothing indicate any problem of any kind.
>
First let's see the output of:
btrfs fi df /mountpoint
You're probably way over allocated in metadata so a balance should help:
btrfs bal start -m /mountpoint
or omit the -m option to run a full balance.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: no space left on device.
2012-11-02 15:54 ` Kyle Gates
@ 2012-11-02 15:59 ` Hugo Mills
2012-11-06 13:23 ` Kenneth Johansson
1 sibling, 0 replies; 45+ messages in thread
From: Hugo Mills @ 2012-11-02 15:59 UTC (permalink / raw)
To: Kyle Gates; +Cc: Kenneth Johansson, linux-btrfs
[-- Attachment #1: Type: text/plain, Size: 1468 bytes --]
On Fri, Nov 02, 2012 at 10:54:47AM -0500, Kyle Gates wrote:
> > So I have ended up in a state where I can't delete files with rm.
> >
> > the error I get is no space on device. however I'm not even close to empty.
> > /dev/sdb1 38G 27G 9.5G 75%
> > there is about 800k files/dirs in this filesystem
> >
> > extra strange is that I can in another directory create and delete files.
> >
> > So I tried pretty much all I could google my way to but problem
> > persisted. So I decided to do a backup and a format. But when the backup
> > was done I tried one more time and now it was possible to delete the
> > directory and all content?
> >
> > using the 3.5 kernel in ubuntu 12.10. Is this a known issue ? is it
> > fixed in later kernels?
> >
> > fsck /btrfs scrub and kernel log. nothing indicate any problem of any kind.
> >
>
> First let's see the output of:
> btrfs fi df /mountpoint
>
> You're probably way over allocated in metadata so a balance should help:
> btrfs bal start -m /mountpoint
> or omit the -m option to run a full balance.
Or, better, -musage=5 (or 1), which will do even less work.
... but let's see the btrfs fi df output first. Could you also add the
output of "btrfs fi show" (no parameters), please?
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
--- You're never alone with a rubber duck... ---
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: no space left on device.
2012-11-02 15:54 ` Kyle Gates
2012-11-02 15:59 ` Hugo Mills
@ 2012-11-06 13:23 ` Kenneth Johansson
1 sibling, 0 replies; 45+ messages in thread
From: Kenneth Johansson @ 2012-11-06 13:23 UTC (permalink / raw)
To: Kyle Gates; +Cc: linux-btrfs
On 11/02/2012 04:54 PM, Kyle Gates wrote:
>> So I have ended up in a state where I can't delete files with rm.
>>
>> the error I get is no space on device. however I'm not even close to empty.
>> /dev/sdb1 38G 27G 9.5G 75%
>> there is about 800k files/dirs in this filesystem
>>
>> extra strange is that I can in another directory create and delete files.
>>
>> So I tried pretty much all I could google my way to but problem
>> persisted. So I decided to do a backup and a format. But when the backup
>> was done I tried one more time and now it was possible to delete the
>> directory and all content?
>>
>> using the 3.5 kernel in ubuntu 12.10. Is this a known issue ? is it
>> fixed in later kernels?
>>
>> fsck /btrfs scrub and kernel log. nothing indicate any problem of any kind.
>>
> First let's see the output of:
> btrfs fi df /mountpoint
>
> You're probably way over allocated in metadata so a balance should help:
> btrfs bal start -m /mountpoint
> or omit the -m option to run a full balance.
I had to use the disk for work so I could not be stuck in that situation
and thus had to nuke the disk.
maybe I can recreate the state I put back mostly the same data again
minus some stuff I did not really need.
So under what circumstance can this actually happen ? why could I
remove/add files in one directory and not another? its the same
partition. And also the filesystem was just a few days old and no
snapshots or anything, well I do use lzo compression but other than that
default values was used to create it.
^ permalink raw reply [flat|nested] 45+ messages in thread
* No space left on device
@ 2014-02-12 9:51 Jakob Truelsen
2014-02-12 10:26 ` Hugo Mills
2014-02-12 10:34 ` Leonidas Spyropoulos
0 siblings, 2 replies; 45+ messages in thread
From: Jakob Truelsen @ 2014-02-12 9:51 UTC (permalink / raw)
To: linux-btrfs
Hello. I am experiencing "No space left on device" with a btrfs file
system, yet I cannot seem to find any exhausted resource. Could some
resource I do not know about be exhausted, or is this caused by
something else. Below is a trace of information that might be usefull,
please let me know if there is anything I can do to resolve the issue.
/Jakob
[jakobt@soda ~]$ uname -a
Linux soda 3.12.8-1-ARCH #1 SMP PREEMPT Thu Jan 16 09:16:34 CET 2014
x86_64 GNU/Linux
[jakobt@soda ~]$ btrfs --version
Btrfs v3.12
[jakobt@soda ~]$ mount
...
/dev/sda on /data type btrfs (rw,relatime,nospace_cache)
[jakobt@soda ~]$ df /data
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sdb2 76594224 49247368 23433028 68% /
[jakobt@soda ~]$ btrfs filesystem df /data
Data, single: total=1.82TiB, used=518.04GiB
System, DUP: total=8.00MiB, used=204.00KiB
System, single: total=4.00MiB, used=0.00
Metadata, DUP: total=1.00GiB, used=767.70MiB
Metadata, single: total=8.00MiB, used=0.00
[jakobt@soda ~]$ touch /data/jakobt/hat
touch: cannot touch ‘/data/jakobt/hat’: No space left on device
[jakobt@soda ~]$ sudo btrfs fi balance start /data
ERROR: error during balancing '/data' - No space left on device
There may be more info in syslog - try dmesg | tail
[jakobt@soda ~]$ dmesg | grep tail -n 2
[1113177.878157] btrfs: device label Data devid 1 transid 44784 /dev/sda
[1113507.641752] btrfs: 1866 enospc errors during balance
[jakobt@soda ~]$ sudo umount /data
[jakobt@soda ~]$ sudo btrfsck /dev/sda
...
cache and super generation don't match, space cache will be invalidated
..
found 172181366447 bytes used err is 0
total csum bytes: 418841160
total tree bytes: 805187584
total fs tree bytes: 247164928
total extent tree bytes: 26329088
btree space waste bytes: 164771401
file data blocks allocated: 561564688384
referenced 511759908864
Btrfs v3.12
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: No space left on device
2014-02-12 9:51 No " Jakob Truelsen
@ 2014-02-12 10:26 ` Hugo Mills
2014-02-12 10:45 ` Jakob Truelsen
2014-02-12 10:34 ` Leonidas Spyropoulos
1 sibling, 1 reply; 45+ messages in thread
From: Hugo Mills @ 2014-02-12 10:26 UTC (permalink / raw)
To: Jakob Truelsen; +Cc: linux-btrfs
[-- Attachment #1: Type: text/plain, Size: 3295 bytes --]
On Wed, Feb 12, 2014 at 10:51:12AM +0100, Jakob Truelsen wrote:
> Hello. I am experiencing "No space left on device" with a btrfs file
> system, yet I cannot seem to find any exhausted resource. Could some
> resource I do not know about be exhausted, or is this caused by
> something else. Below is a trace of information that might be usefull,
> please let me know if there is anything I can do to resolve the issue.
>
> /Jakob
>
> [jakobt@soda ~]$ uname -a
> Linux soda 3.12.8-1-ARCH #1 SMP PREEMPT Thu Jan 16 09:16:34 CET 2014
> x86_64 GNU/Linux
Were you using this kernel when the problem happened?
> [jakobt@soda ~]$ btrfs --version
> Btrfs v3.12
>
> [jakobt@soda ~]$ mount
> ...
> /dev/sda on /data type btrfs (rw,relatime,nospace_cache)
>
> [jakobt@soda ~]$ df /data
> Filesystem 1K-blocks Used Available Use% Mounted on
> /dev/sdb2 76594224 49247368 23433028 68% /
>
> [jakobt@soda ~]$ btrfs filesystem df /data
> Data, single: total=1.82TiB, used=518.04GiB
> System, DUP: total=8.00MiB, used=204.00KiB
> System, single: total=4.00MiB, used=0.00
> Metadata, DUP: total=1.00GiB, used=767.70MiB
^^^ This is your problem, most likely in conjunction with all the
space on the device being allocated. Being a copy-on-write filesystem,
btrfs needs free space to make any update. If it doesn't have that
free space, you get "No space left on device". You typically need
somewhere around 0.5-1 GiB of headroom in metadata for normal
operation, so I'm surprised you got this far. :)
The FS should normally allocate more metadata space as it needs it,
but because (I think) your data allocation has taken up all the
available space on the device, there's no way for it to add more.
> Metadata, single: total=8.00MiB, used=0.00
> [jakobt@soda ~]$ touch /data/jakobt/hat
> touch: cannot touch ‘/data/jakobt/hat’: No space left on device
>
> [jakobt@soda ~]$ sudo btrfs fi balance start /data
> ERROR: error during balancing '/data' - No space left on device
> There may be more info in syslog - try dmesg | tail
Try:
btrfs balance start -dusage=0 /data
which should go looking for entirely unused block groups and reclaim
those. (If you don't use the -dusage= parameter, it will try to
balance everything, which takes a long time).
> [jakobt@soda ~]$ dmesg | grep tail -n 2
> [1113177.878157] btrfs: device label Data devid 1 transid 44784 /dev/sda
> [1113507.641752] btrfs: 1866 enospc errors during balance
Although, that said... it looks like it's tried every block group
and failed with each one, so my suggestion above may not work in this
instance.
Let us know what happens with the balance command above anyway
(dmesg output is useful information at this point). If that doesn't
help, then we'll probably need to take a metadata image and throw it
in josef's direction, where he will start crying at having to deal
with enospc problems again. :)
Hugo.
--
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- If you're not part of the solution, you're part ---
of the precipiate.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: No space left on device
2014-02-12 10:26 ` Hugo Mills
@ 2014-02-12 10:45 ` Jakob Truelsen
2014-02-12 11:07 ` Hugo Mills
0 siblings, 1 reply; 45+ messages in thread
From: Jakob Truelsen @ 2014-02-12 10:45 UTC (permalink / raw)
To: Hugo Mills, Jakob Truelsen, linux-btrfs
Hi and thanks for the quick reply. Have remounted the filesystem with
enospc_debug, and run the rebalance you suggested, with the trance
below. So perhaps the next step is for me to figure out how to take a
metadata image and send it to josef (perhaps with a box of tissues)
/Jakob
[jakobt@soda ~]$ mount
...
/dev/sda on /data type btrfs (rw,relatime,nospace_cache,enospc_debug)
[jakobt@soda ~]$ sudo btrfs balance start -dusage=0 /data
ERROR: error during balancing '/data' - No space left on device
There may be more info in syslog - try dmesg | tail
[jakobt@soda ~]$ touch /data/jakobt/monkey
touch: cannot touch ‘/data/jakobt/monkey’: No space left on device
[jakobt@soda ~]$ dmesg | tail -n3
[1117530.870965] btrfs: device label Data devid 1 transid 47091 /dev/sda
[1117573.087580] btrfs: 426 enospc errors during balance
[1117642.002437] btrfs: 426 enospc errors during balance
On Wed, Feb 12, 2014 at 11:26 AM, Hugo Mills <hugo@carfax.org.uk> wrote:
> On Wed, Feb 12, 2014 at 10:51:12AM +0100, Jakob Truelsen wrote:
>> Hello. I am experiencing "No space left on device" with a btrfs file
>> system, yet I cannot seem to find any exhausted resource. Could some
>> resource I do not know about be exhausted, or is this caused by
>> something else. Below is a trace of information that might be usefull,
>> please let me know if there is anything I can do to resolve the issue.
>>
>> /Jakob
>>
>> [jakobt@soda ~]$ uname -a
>> Linux soda 3.12.8-1-ARCH #1 SMP PREEMPT Thu Jan 16 09:16:34 CET 2014
>> x86_64 GNU/Linux
>
> Were you using this kernel when the problem happened?
>
>> [jakobt@soda ~]$ btrfs --version
>> Btrfs v3.12
>>
>> [jakobt@soda ~]$ mount
>> ...
>> /dev/sda on /data type btrfs (rw,relatime,nospace_cache)
>>
>> [jakobt@soda ~]$ df /data
>> Filesystem 1K-blocks Used Available Use% Mounted on
>> /dev/sdb2 76594224 49247368 23433028 68% /
>>
>> [jakobt@soda ~]$ btrfs filesystem df /data
>> Data, single: total=1.82TiB, used=518.04GiB
>> System, DUP: total=8.00MiB, used=204.00KiB
>> System, single: total=4.00MiB, used=0.00
>> Metadata, DUP: total=1.00GiB, used=767.70MiB
>
> ^^^ This is your problem, most likely in conjunction with all the
> space on the device being allocated. Being a copy-on-write filesystem,
> btrfs needs free space to make any update. If it doesn't have that
> free space, you get "No space left on device". You typically need
> somewhere around 0.5-1 GiB of headroom in metadata for normal
> operation, so I'm surprised you got this far. :)
>
> The FS should normally allocate more metadata space as it needs it,
> but because (I think) your data allocation has taken up all the
> available space on the device, there's no way for it to add more.
>
>> Metadata, single: total=8.00MiB, used=0.00
>
>> [jakobt@soda ~]$ touch /data/jakobt/hat
>> touch: cannot touch ‘/data/jakobt/hat’: No space left on device
>>
>> [jakobt@soda ~]$ sudo btrfs fi balance start /data
>> ERROR: error during balancing '/data' - No space left on device
>> There may be more info in syslog - try dmesg | tail
>
> Try:
>
> btrfs balance start -dusage=0 /data
>
> which should go looking for entirely unused block groups and reclaim
> those. (If you don't use the -dusage= parameter, it will try to
> balance everything, which takes a long time).
>
>> [jakobt@soda ~]$ dmesg | grep tail -n 2
>> [1113177.878157] btrfs: device label Data devid 1 transid 44784 /dev/sda
>> [1113507.641752] btrfs: 1866 enospc errors during balance
>
> Although, that said... it looks like it's tried every block group
> and failed with each one, so my suggestion above may not work in this
> instance.
>
> Let us know what happens with the balance command above anyway
> (dmesg output is useful information at this point). If that doesn't
> help, then we'll probably need to take a metadata image and throw it
> in josef's direction, where he will start crying at having to deal
> with enospc problems again. :)
>
> Hugo.
>
> --
> === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
> PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
> --- If you're not part of the solution, you're part ---
> of the precipiate.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: No space left on device
2014-02-12 10:45 ` Jakob Truelsen
@ 2014-02-12 11:07 ` Hugo Mills
0 siblings, 0 replies; 45+ messages in thread
From: Hugo Mills @ 2014-02-12 11:07 UTC (permalink / raw)
To: Jakob Truelsen; +Cc: linux-btrfs
[-- Attachment #1: Type: text/plain, Size: 5136 bytes --]
On Wed, Feb 12, 2014 at 11:45:34AM +0100, Jakob Truelsen wrote:
> Hi and thanks for the quick reply. Have remounted the filesystem with
> enospc_debug, and run the rebalance you suggested, with the trance
> below. So perhaps the next step is for me to figure out how to take a
> metadata image and send it to josef (perhaps with a box of tissues)
You can get the metadata image with:
btrfs-image -c9 -t4 /dev/sda image-file-to-create
It will probably be a couple of hundred megabytes in size (your
metadata size, compressed). It will contain filenames and xattrs, so
if those are sensitive, you may want to use -s to hide that
information.
After that, probably the best place to make sure it's not lost is
to open an issue on bugzilla.kernel.org, making sure that you set the
Component to btrfs.
Hugo.
> /Jakob
>
>
> [jakobt@soda ~]$ mount
> ...
> /dev/sda on /data type btrfs (rw,relatime,nospace_cache,enospc_debug)
>
> [jakobt@soda ~]$ sudo btrfs balance start -dusage=0 /data
> ERROR: error during balancing '/data' - No space left on device
> There may be more info in syslog - try dmesg | tail
>
> [jakobt@soda ~]$ touch /data/jakobt/monkey
> touch: cannot touch ‘/data/jakobt/monkey’: No space left on device
>
> [jakobt@soda ~]$ dmesg | tail -n3
> [1117530.870965] btrfs: device label Data devid 1 transid 47091 /dev/sda
> [1117573.087580] btrfs: 426 enospc errors during balance
> [1117642.002437] btrfs: 426 enospc errors during balance
> On Wed, Feb 12, 2014 at 11:26 AM, Hugo Mills <hugo@carfax.org.uk> wrote:
> > On Wed, Feb 12, 2014 at 10:51:12AM +0100, Jakob Truelsen wrote:
> >> Hello. I am experiencing "No space left on device" with a btrfs file
> >> system, yet I cannot seem to find any exhausted resource. Could some
> >> resource I do not know about be exhausted, or is this caused by
> >> something else. Below is a trace of information that might be usefull,
> >> please let me know if there is anything I can do to resolve the issue.
> >>
> >> /Jakob
> >>
> >> [jakobt@soda ~]$ uname -a
> >> Linux soda 3.12.8-1-ARCH #1 SMP PREEMPT Thu Jan 16 09:16:34 CET 2014
> >> x86_64 GNU/Linux
> >
> > Were you using this kernel when the problem happened?
> >
> >> [jakobt@soda ~]$ btrfs --version
> >> Btrfs v3.12
> >>
> >> [jakobt@soda ~]$ mount
> >> ...
> >> /dev/sda on /data type btrfs (rw,relatime,nospace_cache)
> >>
> >> [jakobt@soda ~]$ df /data
> >> Filesystem 1K-blocks Used Available Use% Mounted on
> >> /dev/sdb2 76594224 49247368 23433028 68% /
> >>
> >> [jakobt@soda ~]$ btrfs filesystem df /data
> >> Data, single: total=1.82TiB, used=518.04GiB
> >> System, DUP: total=8.00MiB, used=204.00KiB
> >> System, single: total=4.00MiB, used=0.00
> >> Metadata, DUP: total=1.00GiB, used=767.70MiB
> >
> > ^^^ This is your problem, most likely in conjunction with all the
> > space on the device being allocated. Being a copy-on-write filesystem,
> > btrfs needs free space to make any update. If it doesn't have that
> > free space, you get "No space left on device". You typically need
> > somewhere around 0.5-1 GiB of headroom in metadata for normal
> > operation, so I'm surprised you got this far. :)
> >
> > The FS should normally allocate more metadata space as it needs it,
> > but because (I think) your data allocation has taken up all the
> > available space on the device, there's no way for it to add more.
> >
> >> Metadata, single: total=8.00MiB, used=0.00
> >
> >> [jakobt@soda ~]$ touch /data/jakobt/hat
> >> touch: cannot touch ‘/data/jakobt/hat’: No space left on device
> >>
> >> [jakobt@soda ~]$ sudo btrfs fi balance start /data
> >> ERROR: error during balancing '/data' - No space left on device
> >> There may be more info in syslog - try dmesg | tail
> >
> > Try:
> >
> > btrfs balance start -dusage=0 /data
> >
> > which should go looking for entirely unused block groups and reclaim
> > those. (If you don't use the -dusage= parameter, it will try to
> > balance everything, which takes a long time).
> >
> >> [jakobt@soda ~]$ dmesg | grep tail -n 2
> >> [1113177.878157] btrfs: device label Data devid 1 transid 44784 /dev/sda
> >> [1113507.641752] btrfs: 1866 enospc errors during balance
> >
> > Although, that said... it looks like it's tried every block group
> > and failed with each one, so my suggestion above may not work in this
> > instance.
> >
> > Let us know what happens with the balance command above anyway
> > (dmesg output is useful information at this point). If that doesn't
> > help, then we'll probably need to take a metadata image and throw it
> > in josef's direction, where he will start crying at having to deal
> > with enospc problems again. :)
> >
> > Hugo.
> >
--
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- If you're not part of the solution, you're part ---
of the precipiate.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: No space left on device
2014-02-12 9:51 No " Jakob Truelsen
2014-02-12 10:26 ` Hugo Mills
@ 2014-02-12 10:34 ` Leonidas Spyropoulos
1 sibling, 0 replies; 45+ messages in thread
From: Leonidas Spyropoulos @ 2014-02-12 10:34 UTC (permalink / raw)
To: Jakob Truelsen, linux-btrfs
On 12/02/2014 09:51, Jakob Truelsen wrote:
> Hello. I am experiencing "No space left on device" with a btrfs file
> system, yet I cannot seem to find any exhausted resource. Could some
> resource I do not know about be exhausted, or is this caused by
> something else. Below is a trace of information that might be usefull,
> please let me know if there is anything I can do to resolve the issue.
>
> /Jakob
>
> [jakobt@soda ~]$ uname -a
> Linux soda 3.12.8-1-ARCH #1 SMP PREEMPT Thu Jan 16 09:16:34 CET 2014
> x86_64 GNU/Linux
>
> [jakobt@soda ~]$ btrfs --version
> Btrfs v3.12
>
> [jakobt@soda ~]$ mount
> ...
> /dev/sda on /data type btrfs (rw,relatime,nospace_cache)
>
> [jakobt@soda ~]$ df /data
> Filesystem 1K-blocks Used Available Use% Mounted on
> /dev/sdb2 76594224 49247368 23433028 68% /
>
> [jakobt@soda ~]$ btrfs filesystem df /data
> Data, single: total=1.82TiB, used=518.04GiB
> System, DUP: total=8.00MiB, used=204.00KiB
> System, single: total=4.00MiB, used=0.00
> Metadata, DUP: total=1.00GiB, used=767.70MiB
> Metadata, single: total=8.00MiB, used=0.00
>
> [jakobt@soda ~]$ touch /data/jakobt/hat
> touch: cannot touch ‘/data/jakobt/hat’: No space left on device
>
> [jakobt@soda ~]$ sudo btrfs fi balance start /data
> ERROR: error during balancing '/data' - No space left on device
> There may be more info in syslog - try dmesg | tail
>
> [jakobt@soda ~]$ dmesg | grep tail -n 2
> [1113177.878157] btrfs: device label Data devid 1 transid 44784 /dev/sda
> [1113507.641752] btrfs: 1866 enospc errors during balance
>
> [jakobt@soda ~]$ sudo umount /data
>
> [jakobt@soda ~]$ sudo btrfsck /dev/sda
> ...
> cache and super generation don't match, space cache will be invalidated
> ..
> found 172181366447 bytes used err is 0
> total csum bytes: 418841160
> total tree bytes: 805187584
> total fs tree bytes: 247164928
> total extent tree bytes: 26329088
> btree space waste bytes: 164771401
> file data blocks allocated: 561564688384
> referenced 511759908864
> Btrfs v3.12
> --
> 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
>
Hello Jacob,
Have you tried balancing just the data/metadata chunks only?
Regards,
Leonidas
^ permalink raw reply [flat|nested] 45+ messages in thread
* no space left on device
@ 2012-08-03 10:05 Mark Marshall
2012-08-04 9:14 ` Chris Samuel
2012-08-04 9:26 ` Martin Steigerwald
0 siblings, 2 replies; 45+ messages in thread
From: Mark Marshall @ 2012-08-03 10:05 UTC (permalink / raw)
To: linux-btrfs
Hi,
I am new to btrfs, and just installed a new system with SLED 11 SP2 a
few days ago.
However the system seems to be in a real sad state now, saying there
is no free space left on the device even though there is about 8GB
left on the / filesystem.
A defragment works sometimes but then it goes back to the original
state a day or two later. Other times the command just won't respond.
I've had this happen with 2-3 systems now, is there a solution? I
can't keep going around to users machines and defragmenting all the
time !
Thanks,
Mark
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: no space left on device
2012-08-03 10:05 no " Mark Marshall
@ 2012-08-04 9:14 ` Chris Samuel
2012-08-04 9:26 ` Martin Steigerwald
1 sibling, 0 replies; 45+ messages in thread
From: Chris Samuel @ 2012-08-04 9:14 UTC (permalink / raw)
To: linux-btrfs; +Cc: markmarshall8
Hi Mark,
On 08/03/2012 08:05 PM, Mark Marshall wrote:
> I am new to btrfs, and just installed a new system with SLED 11 SP2 a
> few days ago.
Looking at the release notes for SLED11 SP2 it appears to ship with an
ancient kernel (in btrfs terms), 3.0.10. You will want to upgrade to
*at least* a 3.2.x kernel (I use Kubuntu 12.04 on my work laptop with
btrfs /home and had no issues with its 3.2.x), though it's likely you'll
want to go straight to the current 3.5.x kernel.
Best of luck!
Chris
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: no space left on device
2012-08-03 10:05 no " Mark Marshall
2012-08-04 9:14 ` Chris Samuel
@ 2012-08-04 9:26 ` Martin Steigerwald
1 sibling, 0 replies; 45+ messages in thread
From: Martin Steigerwald @ 2012-08-04 9:26 UTC (permalink / raw)
To: linux-btrfs; +Cc: Mark Marshall
Am Freitag, 3. August 2012 schrieb Mark Marshall:
> Hi,
Hi Mark,
> I am new to btrfs, and just installed a new system with SLED 11 SP2 a
> few days ago.
Now you have a nice SLED 11 SP 2 with official BTRFS support from SUSE.
Did you consider to ask SUSE support? ;)
> However the system seems to be in a real sad state now, saying there
> is no free space left on the device even though there is about 8GB
> left on the / filesystem.
>
> A defragment works sometimes but then it goes back to the original
> state a day or two later. Other times the command just won't respond.
>
> I've had this happen with 2-3 systems now, is there a solution? I
> can't keep going around to users machines and defragmenting all the
> time !
First read and understand
https://btrfs.wiki.kernel.org/index.php/FAQ#Aaargh.21_My_filesystem_is_full.2C_and_I.27ve_put_almost_nothing_into_it.21
plus the following FAQs in there.
Then come back with more information.
Possible a btrfs balance will work to make some trees smaller, but this
depends on the current state of your BTRFS. The information you provided
is not nearly enough for an exact diagnosis. A defragment likely won´t
help tough.
Thanks,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
^ permalink raw reply [flat|nested] 45+ messages in thread
* No space left on device
@ 2012-06-19 12:05 André Øien Langvand
2012-06-19 12:36 ` Geoffrey Wehrman
0 siblings, 1 reply; 45+ messages in thread
From: André Øien Langvand @ 2012-06-19 12:05 UTC (permalink / raw)
To: xfs
[-- Attachment #1.1: Type: text/plain, Size: 3868 bytes --]
Hi,
I know there are quite a few posts regarding similar issues around, but I
can't seem to find a solution or at least an answer to why this is
happening in my case, so I thought I'd try the mailing list and I hope
that's okay.
We have 2 file servers with identical hardware and identical configuration
(Dell R610's, H800 controllers, MD1200 DAS, RAID-5) set up with rsync to
mirror the contents. The content is music in several formats (from PCM WAV
to 64kbit AAC previews), which means file sizes of about 1 - 40mb. Both
systems running SLES 11 SP1. Same kernel (2.6.32.59-0.3-default), same
xfsprogs version (xfsprogs-3.1.1-0.1.36).
My example partition on the source now has 9.9G (of 9.1T) available space
and still doesn't report the drive as full. On the destination, however, it
wont allow me to use any of the remaining 51G. This is obviously a problem
when trying to do mirroring.
Both file systems have been mounted with inode64 option since first mount,
there are plenty of inodes available and I've also verified that there are
noe sparse files (find -type f -printf "%S\t%p\n" 2>/dev/null | gawk '{if
($1 < 1.0) print $1 $2}'), just in case.
I have tried repairing (xfs_repair), defragmenting (xfs_fsr) and alter
imaxpct without any luck. Rsync is run like this: # ionice -c3 rsync -rv
--size-only --progress --delete-before --inplace.
More detailed information on source file system:
# df -k | grep sdg1
/dev/sdg1 9762777052 9752457156 10319896 100% /content/raid31
# df -i | grep sdg1
/dev/sdg1 7471884 2311914 5159970 31% /content/raid31
# xfs_info /dev/sdg1
meta-data=/dev/sdg1 isize=2048 agcount=10, agsize=268435424
blks
= sectsz=512 attr=2
data = bsize=4096 blocks=2441215991, imaxpct=5
= sunit=16 swidth=80 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal bsize=4096 blocks=521728, version=2
= sectsz=512 sunit=16 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
# xfs_db -r "-c freesp -s" /dev/sdg1
from to extents blocks pct
1 1 69981 69981 2.99
2 3 246574 559149 23.86
4 7 315038 1707929 72.88
8 15 561 6374 0.27
total free extents 632154
total free blocks 2343433
average free extent size 3.70706
More detailed information on destination file system:
# df -k | grep sdj1
/dev/sdj1 9762777052 9710148076 52628976 100% /content/sg08/vd08
# df -i | grep sdj1
/dev/sdj1 28622264 2307776 26314488 9% /content/sg08/vd08
# xfs_info /dev/sdj1
meta-data=/dev/sdj1 isize=2048 agcount=10, agsize=268435424
blks
= sectsz=512 attr=2
data = bsize=4096 blocks=2441215991, imaxpct=5
= sunit=16 swidth=80 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal bsize=4096 blocks=521728, version=2
= sectsz=512 sunit=16 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
# xfs_db -r "-c freesp -s" /dev/sdj1
from to extents blocks pct
1 1 81761 81761 0.62
2 3 530258 1147719 8.73
4 7 675864 3551039 27.01
8 15 743089 8363043 63.62
16 31 102 1972 0.02
total free extents 2031074
total free blocks 13145534
average free extent size 6.47221
I would be grateful if anyone could shed some light on why this is
happening or maybe even provide a solution.
Thank you,
André
[-- Attachment #1.2: Type: text/html, Size: 5266 bytes --]
[-- Attachment #2: Type: text/plain, Size: 121 bytes --]
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: No space left on device
2012-06-19 12:05 No " André Øien Langvand
@ 2012-06-19 12:36 ` Geoffrey Wehrman
2012-06-20 6:07 ` Dave Chinner
0 siblings, 1 reply; 45+ messages in thread
From: Geoffrey Wehrman @ 2012-06-19 12:36 UTC (permalink / raw)
To: André Øien Langvand; +Cc: xfs
On Tue, Jun 19, 2012 at 02:05:34PM +0200, André Øien Langvand wrote:
| Hi,
|
| I know there are quite a few posts regarding similar issues around, but I
| can't seem to find a solution or at least an answer to why this is
| happening in my case, so I thought I'd try the mailing list and I hope
| that's okay.
|
| We have 2 file servers with identical hardware and identical configuration
| (Dell R610's, H800 controllers, MD1200 DAS, RAID-5) set up with rsync to
| mirror the contents. The content is music in several formats (from PCM WAV
| to 64kbit AAC previews), which means file sizes of about 1 - 40mb. Both
| systems running SLES 11 SP1. Same kernel (2.6.32.59-0.3-default), same
| xfsprogs version (xfsprogs-3.1.1-0.1.36).
|
| My example partition on the source now has 9.9G (of 9.1T) available space
| and still doesn't report the drive as full. On the destination, however, it
| wont allow me to use any of the remaining 51G. This is obviously a problem
| when trying to do mirroring.
|
| Both file systems have been mounted with inode64 option since first mount,
| there are plenty of inodes available and I've also verified that there are
| noe sparse files (find -type f -printf "%S\t%p\n" 2>/dev/null | gawk '{if
| ($1 < 1.0) print $1 $2}'), just in case.
|
| I have tried repairing (xfs_repair), defragmenting (xfs_fsr) and alter
| imaxpct without any luck. Rsync is run like this: # ionice -c3 rsync -rv
| --size-only --progress --delete-before --inplace.
|
|
| More detailed information on source file system:
|
| # df -k | grep sdg1
| /dev/sdg1 9762777052 9752457156 10319896 100% /content/raid31
|
| # df -i | grep sdg1
| /dev/sdg1 7471884 2311914 5159970 31% /content/raid31
|
| # xfs_info /dev/sdg1
| meta-data=/dev/sdg1 isize=2048 agcount=10, agsize=268435424
| blks
| = sectsz=512 attr=2
| data = bsize=4096 blocks=2441215991, imaxpct=5
| = sunit=16 swidth=80 blks
| naming =version 2 bsize=4096 ascii-ci=0
| log =internal bsize=4096 blocks=521728, version=2
| = sectsz=512 sunit=16 blks, lazy-count=1
| realtime =none extsz=4096 blocks=0, rtextents=0
|
| # xfs_db -r "-c freesp -s" /dev/sdg1
| from to extents blocks pct
| 1 1 69981 69981 2.99
| 2 3 246574 559149 23.86
| 4 7 315038 1707929 72.88
| 8 15 561 6374 0.27
| total free extents 632154
| total free blocks 2343433
| average free extent size 3.70706
|
|
|
| More detailed information on destination file system:
|
| # df -k | grep sdj1
| /dev/sdj1 9762777052 9710148076 52628976 100% /content/sg08/vd08
|
| # df -i | grep sdj1
| /dev/sdj1 28622264 2307776 26314488 9% /content/sg08/vd08
|
| # xfs_info /dev/sdj1
| meta-data=/dev/sdj1 isize=2048 agcount=10, agsize=268435424
| blks
| = sectsz=512 attr=2
| data = bsize=4096 blocks=2441215991, imaxpct=5
| = sunit=16 swidth=80 blks
| naming =version 2 bsize=4096 ascii-ci=0
| log =internal bsize=4096 blocks=521728, version=2
| = sectsz=512 sunit=16 blks, lazy-count=1
| realtime =none extsz=4096 blocks=0, rtextents=0
|
| # xfs_db -r "-c freesp -s" /dev/sdj1
| from to extents blocks pct
| 1 1 81761 81761 0.62
| 2 3 530258 1147719 8.73
| 4 7 675864 3551039 27.01
| 8 15 743089 8363043 63.62
| 16 31 102 1972 0.02
| total free extents 2031074
| total free blocks 13145534
| average free extent size 6.47221
|
|
| I would be grateful if anyone could shed some light on why this is
| happening or maybe even provide a solution.
You are using 2 KiB inodes, so an inode cluster (64 inodes) requires
128 KiB of contiguous space on disk. The freesp output above shows that
the largest possible contiguous free space chunk available is 31 * 4 KiB
or 4 KiB short of 128 KiB. You don't have enough contiguous space to
create a new inode cluster, and your existing inodes are likely all
used. This can be verified using xfs_db:
xfs_db -r -c "sb" -c "p ifree" /dev/sdj1
xfs_fsr does not defragment free space, it only makes the problem worse.
A possible solution:
1. mount the filesystem with the ikeep mount option
2. delete a few large files to free up some contiguous space
3. create a few thousand files to "preallocate" inodes
4. delete the newly created files
The ikeep mount option will prevent the space for inodes from being
reused for other purposes.
--
Geoffrey Wehrman
SGI Building 10 Office: (651)683-5496
2750 Blue Water Road Fax: (651)683-5098
Eagan, MN 55121 E-mail: gwehrman@sgi.com
http://www.sgi.com/products/storage/software/
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: No space left on device
2012-06-19 12:36 ` Geoffrey Wehrman
@ 2012-06-20 6:07 ` Dave Chinner
2012-06-20 15:30 ` André Øien Langvand
0 siblings, 1 reply; 45+ messages in thread
From: Dave Chinner @ 2012-06-20 6:07 UTC (permalink / raw)
To: Geoffrey Wehrman; +Cc: André Øien Langvand, xfs
On Tue, Jun 19, 2012 at 07:36:24AM -0500, Geoffrey Wehrman wrote:
> On Tue, Jun 19, 2012 at 02:05:34PM +0200, André Øien Langvand wrote:
> | Hi,
> |
> | I know there are quite a few posts regarding similar issues around, but I
> | can't seem to find a solution or at least an answer to why this is
> | happening in my case, so I thought I'd try the mailing list and I hope
> | that's okay.
> |
> | We have 2 file servers with identical hardware and identical configuration
> | (Dell R610's, H800 controllers, MD1200 DAS, RAID-5) set up with rsync to
> | mirror the contents. The content is music in several formats (from PCM WAV
> | to 64kbit AAC previews), which means file sizes of about 1 - 40mb. Both
> | systems running SLES 11 SP1. Same kernel (2.6.32.59-0.3-default), same
> | xfsprogs version (xfsprogs-3.1.1-0.1.36).
> |
> | My example partition on the source now has 9.9G (of 9.1T) available space
> | and still doesn't report the drive as full. On the destination, however, it
> | wont allow me to use any of the remaining 51G. This is obviously a problem
> | when trying to do mirroring.
> |
> | Both file systems have been mounted with inode64 option since first mount,
> | there are plenty of inodes available and I've also verified that there are
> | noe sparse files (find -type f -printf "%S\t%p\n" 2>/dev/null | gawk '{if
> | ($1 < 1.0) print $1 $2}'), just in case.
> |
> | I have tried repairing (xfs_repair), defragmenting (xfs_fsr) and alter
> | imaxpct without any luck. Rsync is run like this: # ionice -c3 rsync -rv
> | --size-only --progress --delete-before --inplace.
> |
> |
> | More detailed information on source file system:
> |
> | # df -k | grep sdg1
> | /dev/sdg1 9762777052 9752457156 10319896 100% /content/raid31
> |
> | # df -i | grep sdg1
> | /dev/sdg1 7471884 2311914 5159970 31% /content/raid31
> |
> | # xfs_info /dev/sdg1
> | meta-data=/dev/sdg1 isize=2048 agcount=10, agsize=268435424
> | blks
> | = sectsz=512 attr=2
> | data = bsize=4096 blocks=2441215991, imaxpct=5
> | = sunit=16 swidth=80 blks
> | naming =version 2 bsize=4096 ascii-ci=0
> | log =internal bsize=4096 blocks=521728, version=2
> | = sectsz=512 sunit=16 blks, lazy-count=1
> | realtime =none extsz=4096 blocks=0, rtextents=0
> |
> | # xfs_db -r "-c freesp -s" /dev/sdg1
> | from to extents blocks pct
> | 1 1 69981 69981 2.99
> | 2 3 246574 559149 23.86
> | 4 7 315038 1707929 72.88
> | 8 15 561 6374 0.27
> | total free extents 632154
> | total free blocks 2343433
> | average free extent size 3.70706
> |
> |
> |
> | More detailed information on destination file system:
> |
> | # df -k | grep sdj1
> | /dev/sdj1 9762777052 9710148076 52628976 100% /content/sg08/vd08
> |
> | # df -i | grep sdj1
> | /dev/sdj1 28622264 2307776 26314488 9% /content/sg08/vd08
> |
> | # xfs_info /dev/sdj1
> | meta-data=/dev/sdj1 isize=2048 agcount=10, agsize=268435424
> | blks
> | = sectsz=512 attr=2
> | data = bsize=4096 blocks=2441215991, imaxpct=5
> | = sunit=16 swidth=80 blks
> | naming =version 2 bsize=4096 ascii-ci=0
> | log =internal bsize=4096 blocks=521728, version=2
> | = sectsz=512 sunit=16 blks, lazy-count=1
> | realtime =none extsz=4096 blocks=0, rtextents=0
> |
> | # xfs_db -r "-c freesp -s" /dev/sdj1
> | from to extents blocks pct
> | 1 1 81761 81761 0.62
> | 2 3 530258 1147719 8.73
> | 4 7 675864 3551039 27.01
> | 8 15 743089 8363043 63.62
> | 16 31 102 1972 0.02
> | total free extents 2031074
> | total free blocks 13145534
> | average free extent size 6.47221
> |
> |
> | I would be grateful if anyone could shed some light on why this is
> | happening or maybe even provide a solution.
>
> You are using 2 KiB inodes, so an inode cluster (64 inodes) requires
> 128 KiB of contiguous space on disk. The freesp output above shows that
> the largest possible contiguous free space chunk available is 31 * 4 KiB
> or 4 KiB short of 128 KiB. You don't have enough contiguous space to
> create a new inode cluster, and your existing inodes are likely all
> used. This can be verified using xfs_db:
> xfs_db -r -c "sb" -c "p ifree" /dev/sdj1
>
> xfs_fsr does not defragment free space, it only makes the problem worse.
> A possible solution:
> 1. mount the filesystem with the ikeep mount option
> 2. delete a few large files to free up some contiguous space
large -contiguous- files. It's likely any files written recently
will be as fragmented as the free space....
> 3. create a few thousand files to "preallocate" inodes
> 4. delete the newly created files
That will work for a while, but it's really just a temporary
workaround until those "preallocated" inodes are exhausted. Normally
to recover from this situation you need to free 15-20% of the disk
space to allow sufficiently large contiguous free space extents to
reform naturally and allow the allocator to work at full efficiency
again....
> The ikeep mount option will prevent the space for inodes from being
> reused for other purposes.
The problem with using ikeep is that the remaining empty inode
chunks prevent free space from defragmenting itself fully as you
remove files from the filesystem.
Realistically, I think the problem is that you are running your
filesystems at near ENOSPC for extended periods of time. That is
guaranteed to fragment free space and any files that are written
when the filesytem is in this condition. As Geoffrey has said -
xfs_fsr will not fix your problems - only changing the way you use
your storage will prevent the problem from occurring again.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: No space left on device
2012-06-20 6:07 ` Dave Chinner
@ 2012-06-20 15:30 ` André Øien Langvand
0 siblings, 0 replies; 45+ messages in thread
From: André Øien Langvand @ 2012-06-20 15:30 UTC (permalink / raw)
To: Dave Chinner; +Cc: xfs
[-- Attachment #1.1: Type: text/plain, Size: 6994 bytes --]
Thank you both for informative replies, much appreciated.
I ended up doing the tedious job of shuffling data around to get a more
reasonable distance to ENOSPC, as there was no way I could free up the
needed contiguous free space with my dataset.
Thanks,
André
On 20 June 2012 08:07, Dave Chinner <david@fromorbit.com> wrote:
> On Tue, Jun 19, 2012 at 07:36:24AM -0500, Geoffrey Wehrman wrote:
> > On Tue, Jun 19, 2012 at 02:05:34PM +0200, André Øien Langvand wrote:
> > | Hi,
> > |
> > | I know there are quite a few posts regarding similar issues around,
> but I
> > | can't seem to find a solution or at least an answer to why this is
> > | happening in my case, so I thought I'd try the mailing list and I hope
> > | that's okay.
> > |
> > | We have 2 file servers with identical hardware and identical
> configuration
> > | (Dell R610's, H800 controllers, MD1200 DAS, RAID-5) set up with rsync
> to
> > | mirror the contents. The content is music in several formats (from PCM
> WAV
> > | to 64kbit AAC previews), which means file sizes of about 1 - 40mb. Both
> > | systems running SLES 11 SP1. Same kernel (2.6.32.59-0.3-default), same
> > | xfsprogs version (xfsprogs-3.1.1-0.1.36).
> > |
> > | My example partition on the source now has 9.9G (of 9.1T) available
> space
> > | and still doesn't report the drive as full. On the destination,
> however, it
> > | wont allow me to use any of the remaining 51G. This is obviously a
> problem
> > | when trying to do mirroring.
> > |
> > | Both file systems have been mounted with inode64 option since first
> mount,
> > | there are plenty of inodes available and I've also verified that there
> are
> > | noe sparse files (find -type f -printf "%S\t%p\n" 2>/dev/null | gawk
> '{if
> > | ($1 < 1.0) print $1 $2}'), just in case.
> > |
> > | I have tried repairing (xfs_repair), defragmenting (xfs_fsr) and alter
> > | imaxpct without any luck. Rsync is run like this: # ionice -c3 rsync
> -rv
> > | --size-only --progress --delete-before --inplace.
> > |
> > |
> > | More detailed information on source file system:
> > |
> > | # df -k | grep sdg1
> > | /dev/sdg1 9762777052 9752457156 10319896 100%
> /content/raid31
> > |
> > | # df -i | grep sdg1
> > | /dev/sdg1 7471884 2311914 5159970 31% /content/raid31
> > |
> > | # xfs_info /dev/sdg1
> > | meta-data=/dev/sdg1 isize=2048 agcount=10,
> agsize=268435424
> > | blks
> > | = sectsz=512 attr=2
> > | data = bsize=4096 blocks=2441215991,
> imaxpct=5
> > | = sunit=16 swidth=80 blks
> > | naming =version 2 bsize=4096 ascii-ci=0
> > | log =internal bsize=4096 blocks=521728, version=2
> > | = sectsz=512 sunit=16 blks,
> lazy-count=1
> > | realtime =none extsz=4096 blocks=0, rtextents=0
> > |
> > | # xfs_db -r "-c freesp -s" /dev/sdg1
> > | from to extents blocks pct
> > | 1 1 69981 69981 2.99
> > | 2 3 246574 559149 23.86
> > | 4 7 315038 1707929 72.88
> > | 8 15 561 6374 0.27
> > | total free extents 632154
> > | total free blocks 2343433
> > | average free extent size 3.70706
> > |
> > |
> > |
> > | More detailed information on destination file system:
> > |
> > | # df -k | grep sdj1
> > | /dev/sdj1 9762777052 9710148076 52628976 100%
> /content/sg08/vd08
> > |
> > | # df -i | grep sdj1
> > | /dev/sdj1 28622264 2307776 26314488 9% /content/sg08/vd08
> > |
> > | # xfs_info /dev/sdj1
> > | meta-data=/dev/sdj1 isize=2048 agcount=10,
> agsize=268435424
> > | blks
> > | = sectsz=512 attr=2
> > | data = bsize=4096 blocks=2441215991,
> imaxpct=5
> > | = sunit=16 swidth=80 blks
> > | naming =version 2 bsize=4096 ascii-ci=0
> > | log =internal bsize=4096 blocks=521728, version=2
> > | = sectsz=512 sunit=16 blks,
> lazy-count=1
> > | realtime =none extsz=4096 blocks=0, rtextents=0
> > |
> > | # xfs_db -r "-c freesp -s" /dev/sdj1
> > | from to extents blocks pct
> > | 1 1 81761 81761 0.62
> > | 2 3 530258 1147719 8.73
> > | 4 7 675864 3551039 27.01
> > | 8 15 743089 8363043 63.62
> > | 16 31 102 1972 0.02
> > | total free extents 2031074
> > | total free blocks 13145534
> > | average free extent size 6.47221
> > |
> > |
> > | I would be grateful if anyone could shed some light on why this is
> > | happening or maybe even provide a solution.
> >
> > You are using 2 KiB inodes, so an inode cluster (64 inodes) requires
> > 128 KiB of contiguous space on disk. The freesp output above shows that
> > the largest possible contiguous free space chunk available is 31 * 4 KiB
> > or 4 KiB short of 128 KiB. You don't have enough contiguous space to
> > create a new inode cluster, and your existing inodes are likely all
> > used. This can be verified using xfs_db:
> > xfs_db -r -c "sb" -c "p ifree" /dev/sdj1
> >
> > xfs_fsr does not defragment free space, it only makes the problem worse.
> > A possible solution:
> > 1. mount the filesystem with the ikeep mount option
> > 2. delete a few large files to free up some contiguous space
>
> large -contiguous- files. It's likely any files written recently
> will be as fragmented as the free space....
>
> > 3. create a few thousand files to "preallocate" inodes
> > 4. delete the newly created files
>
> That will work for a while, but it's really just a temporary
> workaround until those "preallocated" inodes are exhausted. Normally
> to recover from this situation you need to free 15-20% of the disk
> space to allow sufficiently large contiguous free space extents to
> reform naturally and allow the allocator to work at full efficiency
> again....
>
> > The ikeep mount option will prevent the space for inodes from being
> > reused for other purposes.
>
> The problem with using ikeep is that the remaining empty inode
> chunks prevent free space from defragmenting itself fully as you
> remove files from the filesystem.
>
> Realistically, I think the problem is that you are running your
> filesystems at near ENOSPC for extended periods of time. That is
> guaranteed to fragment free space and any files that are written
> when the filesytem is in this condition. As Geoffrey has said -
> xfs_fsr will not fix your problems - only changing the way you use
> your storage will prevent the problem from occurring again.
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@fromorbit.com
>
[-- Attachment #1.2: Type: text/html, Size: 8600 bytes --]
[-- Attachment #2: Type: text/plain, Size: 121 bytes --]
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 45+ messages in thread
[parent not found: <AANLkTinH225vC8fRbA7zk_iOEmyADFZMBS6b7gx1tOxm@mail.gmail.com>]
* Re: no space left on device
[not found] <AANLkTinH225vC8fRbA7zk_iOEmyADFZMBS6b7gx1tOxm@mail.gmail.com>
@ 2011-02-08 9:00 ` Leonidas Spyropoulos
2011-02-08 9:31 ` cwillu
0 siblings, 1 reply; 45+ messages in thread
From: Leonidas Spyropoulos @ 2011-02-08 9:00 UTC (permalink / raw)
To: C Anthony Risinger; +Cc: linux-btrfs
On Feb 8, 2011 12:09 AM, "C Anthony Risinger" <anthony@extof.me> wrote:
>
> On Mon, Feb 7, 2011 at 3:21 PM, Leonidas Spyropoulos
> <artafinde@gmail.com> wrote:
> > Hey all,
> >
> > I run into no space left on device on a virtualbox
> >
> > After installing Debian 6 on a virtual machine
> > I tried installing the KDE desktop
> >
> > The system HDD is 8Gb
> > Both root (/) and /home are btrfs
> > over LVM.
> >
> > While installing the packages I run into:
> >
> > no space left, need 4096, 4096 dealloc bytes, 1776283648 bytes_used, 0
> > bytes_reserved,
> > 0 bytes_pinned, 0 bytes_readonly, 0 may use 1776287744 total
> >
> > df shows only 74% used space on /
> >
> > kernel used: stock debian 6 2.6.32-5-686
> >
> > At the moment I cannot access it with normal boot, only recovery mode.
> >
> > I can provide whatever info you would like as long as you think of a
> > way to load the normal system and not the recovery mode.
>
> IIRC .32 has all sorts of ENOSPC problems; I think this was seriously
> tackled in kernels > .32... this kernel was only declared ready for
> "early adopters", with an "expect issues" disclaimer.
>
> The btrfs-tools in squeeze is probably so old you may not even have
> the `btrfs` binary, but I don't run debian so I'm not sure there...
> not really a solution probably for you, but I wouldn't run that kernel
> if using btrfs.
>
> C Anthony
Hey all,
Thanks for all the answers.
The problem is that I cannot login to the system.only recovery mode works,
and there btrfs command is not there as you imagined.
I will try though ssh but I don't think it's installed by default and I
cannot install it.
So the next step is try from recovery console of debian live cd, which still
has the really old tools...
I think this is quite some serious issue but generally all debian's fault
adopting a btrfs file system support on a 2.6.32 kernel and without
btrfs-progs on some decent version.
I'll update when possible.
Please throw any other alternatives my way anyone.
Thanks,
Leonidas
--
Caution: breathing may be hazardous to your health.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: no space left on device
2011-02-08 9:00 ` no " Leonidas Spyropoulos
@ 2011-02-08 9:31 ` cwillu
2011-02-08 10:08 ` Leonidas Spyropoulos
0 siblings, 1 reply; 45+ messages in thread
From: cwillu @ 2011-02-08 9:31 UTC (permalink / raw)
To: Leonidas Spyropoulos; +Cc: C Anthony Risinger, linux-btrfs
On Tue, Feb 8, 2011 at 3:00 AM, Leonidas Spyropoulos
<artafinde@gmail.com> wrote:
> On Feb 8, 2011 12:09 AM, "C Anthony Risinger" <anthony@extof.me> wrote:
>>
>> On Mon, Feb 7, 2011 at 3:21 PM, Leonidas Spyropoulos
>> <artafinde@gmail.com> wrote:
>> > Hey all,
>> >
>> > I run into no space left on device on a virtualbox
>> >
>> > After installing Debian 6 on a virtual machine
>> > I tried installing the KDE desktop
>> >
>> > The system HDD is 8Gb
>> > Both root (/) and /home are btrfs
>> > over LVM.
>> >
>> > While installing the packages I run into:
>> >
>> > no space left, need 4096, 4096 dealloc bytes, 1776283648 bytes_used, 0
>> > bytes_reserved,
>> > 0 bytes_pinned, 0 bytes_readonly, 0 may use 1776287744 total
>> >
>> > df shows only 74% used space on /
>> >
>> > kernel used: stock debian 6 2.6.32-5-686
>> >
>> > At the moment I cannot access it with normal boot, only recovery mode.
>> >
>> > I can provide whatever info you would like as long as you think of a
>> > way to load the normal system and not the recovery mode.
>>
>> IIRC .32 has all sorts of ENOSPC problems; I think this was seriously
>> tackled in kernels > .32... this kernel was only declared ready for
>> "early adopters", with an "expect issues" disclaimer.
>>
>> The btrfs-tools in squeeze is probably so old you may not even have
>> the `btrfs` binary, but I don't run debian so I'm not sure there...
>> not really a solution probably for you, but I wouldn't run that kernel
>> if using btrfs.
>>
>> C Anthony
>
> Hey all,
>
> Thanks for all the answers.
>
> The problem is that I cannot login to the system.only recovery mode works,
> and there btrfs command is not there as you imagined.
>
> I will try though ssh but I don't think it's installed by default and I
> cannot install it.
>
> So the next step is try from recovery console of debian live cd, which still
> has the really old tools...
>
> I think this is quite some serious issue but generally all debian's fault
> adopting a btrfs file system support on a 2.6.32 kernel and without
> btrfs-progs on some decent version.
>
> I'll update when possible.
> Please throw any other alternatives my way anyone.
I have to be blunt, blaming your problems on debian isn't terribly
classy. The "oooo, shiny!" reflex is your fault, not debian's.
Download and install a prebuilt 2.6.35 or later kernel into your /boot
via a livecd or whatever, unpack and add the btrfs command to the
initramfs for that kernel, boot up into that initramfs with the kernel
option "break=premount", and fix the rootfs from the busybox prompt.
Alternatively, an ubuntu natty alpha livecd has a 2.6.38 kernel, and
you can install mostly up-to-date btrfs tools into that environment.
I'm sure debian has something similar available.
--Carey Underwood
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: no space left on device
2011-02-08 9:31 ` cwillu
@ 2011-02-08 10:08 ` Leonidas Spyropoulos
2011-02-08 13:19 ` Helmut Hullen
0 siblings, 1 reply; 45+ messages in thread
From: Leonidas Spyropoulos @ 2011-02-08 10:08 UTC (permalink / raw)
To: cwillu; +Cc: C Anthony Risinger, linux-btrfs
On 8 February 2011 09:31, cwillu <cwillu@cwillu.com> wrote:
> On Tue, Feb 8, 2011 at 3:00 AM, Leonidas Spyropoulos
> <artafinde@gmail.com> wrote:
>> On Feb 8, 2011 12:09 AM, "C Anthony Risinger" <anthony@extof.me> wro=
te:
>>>
>>> On Mon, Feb 7, 2011 at 3:21 PM, Leonidas Spyropoulos
>>> <artafinde@gmail.com> wrote:
>>> > Hey all,
>>> >
>>> > I run into no space left on device on a virtualbox
>>> >
>>> > After installing Debian 6 on a virtual machine
>>> > I tried installing the KDE desktop
>>> >
>>> > The system HDD is 8Gb
>>> > Both root (/) and /home are btrfs
>>> > over LVM.
>>> >
>>> > While installing the packages I run into:
>>> >
>>> > no space left, need 4096, 4096 dealloc bytes, 1776283648 bytes_us=
ed, 0
>>> > bytes_reserved,
>>> > 0 bytes_pinned, 0 bytes_readonly, 0 may use 1776287744 total
>>> >
>>> > df shows only 74% used space on /
>>> >
>>> > kernel used: stock debian 6 2.6.32-5-686
>>> >
>>> > At the moment I cannot access it with normal boot, only recovery =
mode.
>>> >
>>> > I can provide whatever info you would like as long as you think o=
f a
>>> > way to load the normal system and not the recovery mode.
>>>
>>> IIRC .32 has all sorts of ENOSPC problems; I think this was serious=
ly
>>> tackled in kernels > .32... this kernel was only declared ready for
>>> "early adopters", with an "expect issues" disclaimer.
>>>
>>> The btrfs-tools in squeeze is probably so old you may not even have
>>> the `btrfs` binary, but I don't run debian so I'm not sure there...
>>> not really a solution probably for you, but I wouldn't run that ker=
nel
>>> if using btrfs.
>>>
>>> C Anthony
>>
>> Hey all,
>>
>> Thanks for all the answers.
>>
>> The problem is that I cannot login to the system.only recovery mode =
works,
>> and there btrfs command is not there as you imagined.
>>
>> I will try though ssh but I don't think it's installed by default an=
d I
>> cannot install it.
>>
>> So the next step is try from recovery console of debian live cd, whi=
ch still
>> has the really old tools...
>>
>> I think this is quite some serious issue but generally all debian's =
fault
>> adopting a btrfs file system support on a 2.6.32 kernel and without
>> btrfs-progs on some decent version.
>>
>> I'll update when possible.
>> Please throw any other alternatives my way anyone.
>
> I have to be blunt, blaming your problems on debian isn't terribly
> classy. =A0The "oooo, shiny!" reflex is your fault, not debian's.
Well you are right it is my problem and yeah I wanted to test the "new
shiny" Debian 6 with
officially btrfs supported.
=46or the moment I apt-get clean to get some space since my / was
updating the KDE (so it had a lot of cache files there)
Reserved something like 300Mb and then vlextend the /
But the next step is to update kernel and btrfs-progs from git.
Thanks for answers
>
> Download and install a prebuilt 2.6.35 or later kernel into your /boo=
t
> via a livecd or whatever, unpack and add the btrfs command to the
> initramfs for that kernel, boot up into that initramfs with the kerne=
l
> option "break=3Dpremount", and fix the rootfs from the busybox prompt=
=2E
The above seems unknown to me. Could you elaborate a bit please?
>
> Alternatively, an ubuntu natty alpha livecd has a 2.6.38 kernel, and
> you can install mostly up-to-date btrfs tools into that environment.
> I'm sure debian has something similar available.
I was wondering how to fix this without liveCD.
>
> --Carey Underwood
>
--=20
Caution: breathing may be hazardous to your health.
--
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] 45+ messages in thread
* Re: no space left on device
2011-02-08 10:08 ` Leonidas Spyropoulos
@ 2011-02-08 13:19 ` Helmut Hullen
2011-02-08 18:56 ` Erik Logtenberg
0 siblings, 1 reply; 45+ messages in thread
From: Helmut Hullen @ 2011-02-08 13:19 UTC (permalink / raw)
To: linux-btrfs
Hallo, Leonidas,
Du meintest am 08.02.11:
[...]
>> I have to be blunt, blaming your problems on debian isn't terribly
>> classy. =A0The "oooo, shiny!" reflex is your fault, not debian's.
> Well you are right it is my problem and yeah I wanted to test the
> "new shiny" Debian 6 with officially btrfs supported.
It's my problem too - I have to restore about 1.5 TByte somehow ...
> For the moment I apt-get clean to get some space since my / was
> updating the KDE (so it had a lot of cache files there)
> Reserved something like 300Mb and then vlextend the /
> But the next step is to update kernel and btrfs-progs from git.
Maybe that doesn't help now. I'm working with kernel 2.6.37 and kernel =
=20
2.6.38-rc2, and I've got big problems.
Viele Gruesse!
Helmut
--
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] 45+ messages in thread
* Re: no space left on device
2011-02-08 13:19 ` Helmut Hullen
@ 2011-02-08 18:56 ` Erik Logtenberg
2011-02-08 19:43 ` Helmut Hullen
2011-02-08 20:36 ` Helmut Hullen
0 siblings, 2 replies; 45+ messages in thread
From: Erik Logtenberg @ 2011-02-08 18:56 UTC (permalink / raw)
To: linux-btrfs
>> But the next step is to update kernel and btrfs-progs from git.
>
> Maybe that doesn't help now. I'm working with kernel 2.6.37 and kernel
> 2.6.38-rc2, and I've got big problems.
I had to install at least 2.6.37 to have a kernel with an advanced
enough balance feature to actually reclaim the free space and report it
correctly too.
Still, I had so much kernel crashes during this balance operation that
even after numerous retries I still hadn't once completed it (on a FS of
merely 300GB). Fortunately Zheng Yan coded a patch, which I applied to
2.6.38-rc2, so that I could finally run - and finish - the balance
operation.
Additionally this version of btrfs is more clever in not wasting the
free space to begin with, hence making future rebalances for reclaiming
free space no longer necessary.
That patch is released on this list on january 26th, called "Fix balance
panic". If you experience the same, you could try applying this patch
too. There is no (pre-built) kernel yet with this patch already applied.
- Erik.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: no space left on device
2011-02-08 18:56 ` Erik Logtenberg
@ 2011-02-08 19:43 ` Helmut Hullen
2011-02-12 14:11 ` Erik Logtenberg
2011-02-08 20:36 ` Helmut Hullen
1 sibling, 1 reply; 45+ messages in thread
From: Helmut Hullen @ 2011-02-08 19:43 UTC (permalink / raw)
To: linux-btrfs
Hallo, Erik,
Du meintest am 08.02.11:
>>> But the next step is to update kernel and btrfs-progs from git.
>> Maybe that doesn't help now. I'm working with kernel 2.6.37 and
>> kernel 2.6.38-rc2, and I've got big problems.
[...]
> Fortunately Zheng Yan coded a patch, which I
> applied to 2.6.38-rc2, so that I could finally run - and finish - the
> balance operation.
[...]
> That patch is released on this list on january 26th, called "Fix
> balance panic". If you experience the same, you could try applying
> this patch too. There is no (pre-built) kernel yet with this patch
> already applied.
Maybe it will help. But my actual problem is: I cannot mount the btrfs
system (it leads to "kernel panic"). And starting "btrfs filesystem
balance ..." requires a mounted btrfs system.
I'll see ...
Viele Gruesse!
Helmut
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: no space left on device
2011-02-08 19:43 ` Helmut Hullen
@ 2011-02-12 14:11 ` Erik Logtenberg
0 siblings, 0 replies; 45+ messages in thread
From: Erik Logtenberg @ 2011-02-12 14:11 UTC (permalink / raw)
To: helmut; +Cc: linux-btrfs
>> That patch is released on this list on january 26th, called "Fix
>> balance panic". If you experience the same, you could try applying
>> this patch too. There is no (pre-built) kernel yet with this patch
>> already applied.
>
> Maybe it will help. But my actual problem is: I cannot mount the btrfs
> system (it leads to "kernel panic"). And starting "btrfs filesystem
> balance ..." requires a mounted btrfs system.
Yeah sorry, I hadn't noticed that. No, that patch will certainly not fix
a filesystem you can't mount to begin with. Can't help you out.
- Erik
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: no space left on device
2011-02-08 18:56 ` Erik Logtenberg
2011-02-08 19:43 ` Helmut Hullen
@ 2011-02-08 20:36 ` Helmut Hullen
1 sibling, 0 replies; 45+ messages in thread
From: Helmut Hullen @ 2011-02-08 20:36 UTC (permalink / raw)
To: linux-btrfs
Hallo, Erik,
Du meintest am 08.02.11:
[...]
> Fortunately Zheng Yan coded a patch, which I
> applied to 2.6.38-rc2, so that I could finally run - and finish - the
> balance operation.
> Additionally this version of btrfs is more clever in not wasting the
> free space to begin with, hence making future rebalances for
> reclaiming free space no longer necessary.
That patch isn't yet included in 2.6.38-rc4.
Viele Gruesse!
Helmut
^ permalink raw reply [flat|nested] 45+ messages in thread
* no space left on device
@ 2011-02-07 21:21 Leonidas Spyropoulos
2011-02-07 21:27 ` Erik Logtenberg
2011-02-08 0:09 ` C Anthony Risinger
0 siblings, 2 replies; 45+ messages in thread
From: Leonidas Spyropoulos @ 2011-02-07 21:21 UTC (permalink / raw)
To: linux-btrfs
Hey all,
I run into no space left on device on a virtualbox
After installing Debian 6 on a virtual machine
I tried installing the KDE desktop
The system HDD is 8Gb
Both root (/) and /home are btrfs
over LVM.
While installing the packages I run into:
no space left, need 4096, 4096 dealloc bytes, 1776283648 bytes_used, 0
bytes_reserved,
0 bytes_pinned, 0 bytes_readonly, 0 may use 1776287744 total
df shows only 74% used space on /
kernel used: stock debian 6 2.6.32-5-686
At the moment I cannot access it with normal boot, only recovery mode.
I can provide whatever info you would like as long as you think of a
way to load the normal system and not the recovery mode.
--
Caution: breathing may be hazardous to your health.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: no space left on device
2011-02-07 21:21 Leonidas Spyropoulos
@ 2011-02-07 21:27 ` Erik Logtenberg
2011-02-07 23:58 ` Robert G.
2011-02-08 0:09 ` C Anthony Risinger
1 sibling, 1 reply; 45+ messages in thread
From: Erik Logtenberg @ 2011-02-07 21:27 UTC (permalink / raw)
Cc: linux-btrfs
Hi Leonidas,
Please check this:
btrfs fi df /home
If this shows much of your space used by metadata then please use:
btrfs fi balance /home
Note that this can take a long (>1 day) time to complete on a big FS.
- Erik
On 02/07/2011 10:21 PM, Leonidas Spyropoulos wrote:
> Hey all,
>
> I run into no space left on device on a virtualbox
>
> After installing Debian 6 on a virtual machine
> I tried installing the KDE desktop
>
> The system HDD is 8Gb
> Both root (/) and /home are btrfs
> over LVM.
>
> While installing the packages I run into:
>
> no space left, need 4096, 4096 dealloc bytes, 1776283648 bytes_used, 0
> bytes_reserved,
> 0 bytes_pinned, 0 bytes_readonly, 0 may use 1776287744 total
>
> df shows only 74% used space on /
>
> kernel used: stock debian 6 2.6.32-5-686
>
> At the moment I cannot access it with normal boot, only recovery mode.
>
> I can provide whatever info you would like as long as you think of a
> way to load the normal system and not the recovery mode.
>
>
>
>
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: no space left on device
2011-02-07 21:27 ` Erik Logtenberg
@ 2011-02-07 23:58 ` Robert G.
0 siblings, 0 replies; 45+ messages in thread
From: Robert G. @ 2011-02-07 23:58 UTC (permalink / raw)
To: Erik Logtenberg; +Cc: linux-btrfs
Hi,
I had a similar problem on my Debian (squeeze) about a half year ago.
I've described that on this mailing list. That was a main reason to
migrate from brtfs (-o ssd) to ext4.=20
I know it's a pain for my SSD but I want to revert this fail system
when it will be more stable. Thanks God it was added to Debian 6 and
Ubuntu 10.10. Now there will be even more alpha/beta testers.
And some problems will be noticed more frequently.
When will you change status from experimental to stable in the kernel?
Regards
Robert.
Dnia 2011-02-07, o godz. 22:27:14
Erik Logtenberg <erik@logtenberg.eu> napisa=C5=82(a):
> Hi Leonidas,
>=20
> Please check this:
>=20
> btrfs fi df /home
>=20
> If this shows much of your space used by metadata then please use:
>=20
> btrfs fi balance /home
>=20
> Note that this can take a long (>1 day) time to complete on a big FS.
>=20
> - Erik
>=20
>=20
>=20
> On 02/07/2011 10:21 PM, Leonidas Spyropoulos wrote:
> > Hey all,
> >=20
> > I run into no space left on device on a virtualbox
> >=20
> > After installing Debian 6 on a virtual machine
> > I tried installing the KDE desktop
> >=20
> > The system HDD is 8Gb
> > Both root (/) and /home are btrfs
> > over LVM.
> >=20
> > While installing the packages I run into:
> >=20
> > no space left, need 4096, 4096 dealloc bytes, 1776283648
> > bytes_used, 0 bytes_reserved,
> > 0 bytes_pinned, 0 bytes_readonly, 0 may use 1776287744 total
> >=20
> > df shows only 74% used space on /
> >=20
> > kernel used: stock debian 6 2.6.32-5-686
> >=20
> > At the moment I cannot access it with normal boot, only recovery
> > mode.
> >=20
> > I can provide whatever info you would like as long as you think of =
a
> > way to load the normal system and not the recovery mode.
> >=20
> >=20
> >=20
> >=20
>=20
> --
> 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
--
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] 45+ messages in thread
* Re: no space left on device
2011-02-07 21:21 Leonidas Spyropoulos
2011-02-07 21:27 ` Erik Logtenberg
@ 2011-02-08 0:09 ` C Anthony Risinger
1 sibling, 0 replies; 45+ messages in thread
From: C Anthony Risinger @ 2011-02-08 0:09 UTC (permalink / raw)
To: Leonidas Spyropoulos; +Cc: linux-btrfs
On Mon, Feb 7, 2011 at 3:21 PM, Leonidas Spyropoulos
<artafinde@gmail.com> wrote:
> Hey all,
>
> I run into no space left on device on a virtualbox
>
> After installing Debian 6 on a virtual machine
> I tried installing the KDE desktop
>
> The system HDD is 8Gb
> Both root (/) and /home are btrfs
> over LVM.
>
> While installing the packages I run into:
>
> no space left, need 4096, 4096 dealloc bytes, 1776283648 bytes_used, 0
> bytes_reserved,
> 0 bytes_pinned, 0 bytes_readonly, 0 may use 1776287744 total
>
> df shows only 74% used space on /
>
> kernel used: stock debian 6 2.6.32-5-686
>
> At the moment I cannot access it with normal boot, only recovery mode.
>
> I can provide whatever info you would like as long as you think of a
> way to load the normal system and not the recovery mode.
IIRC .32 has all sorts of ENOSPC problems; I think this was seriously
tackled in kernels > .32... this kernel was only declared ready for
"early adopters", with an "expect issues" disclaimer.
The btrfs-tools in squeeze is probably so old you may not even have
the `btrfs` binary, but I don't run debian so I'm not sure there...
not really a solution probably for you, but I wouldn't run that kernel
if using btrfs.
C Anthony
^ permalink raw reply [flat|nested] 45+ messages in thread
* No space left on device
@ 2010-09-24 14:07 Turbo Fredriksson
2010-09-24 15:23 ` Geoffrey Wehrman
2010-09-25 2:18 ` Dave Chinner
0 siblings, 2 replies; 45+ messages in thread
From: Turbo Fredriksson @ 2010-09-24 14:07 UTC (permalink / raw)
To: xfs
I started with a few hundred gig on my FS
(on top of LVM which in turn is on top a bunch
of MD devices).
Slowly increasing the size with pvmove/{vg,lv}extend
etc. Yesterday, I added more disks yet again and
now have about 8Tb on one FS... ~1Tb free. But still
get the 'No space left on device'.
I've been looking through the 'Net and it
must be because I'm out of inodes (and that
the data is on the first 1Tb etc)...
I'm running on AMD 64bit (native kernel, but
Debian Lenny 32bit userland - 2.6.2[4-6] kernel).
Now, if I use (I'll try to upgrade to a newer
kernel so I can reverse) the inode64, what
impact will this have? I guess I still have
to move my firstly created 1Tb of-disk and
then back again?
The worst thing is that every time I grow
the FS, I have to reboot into a 32bit kernel:
xfs_growfs: XFS_IOC_FSGROWFSDATA xfsctl failed: Invalid argument
and then back to the 64bit kernel... How will
this (system/FS) react if I go 64bit inodes?!
And how safe is this!? I just don't have the
possibility to do a full backup of all this
data, not even temporarily... I _might_ be
able to do this in a few weeks (work is ordering
a bunch of LaCie 8Tb USB/eSATA storage boxes
which I might be able to load for a few days
'to do some stress testing on' :)
References:
http://xfs.org/index.php/XFS_FAQ#Q:_Why_do_I_receive_No_space_left_on_device_after_xfs_growfs.3F
http://xfs.org/index.php/XFS_FAQ#Q:_Can_I_just_try_the_inode64_option_to_see_if_it_helps_me.3F
http://www.doc.ic.ac.uk/~dcw/xfs_16tb/
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: No space left on device
2010-09-24 14:07 No " Turbo Fredriksson
@ 2010-09-24 15:23 ` Geoffrey Wehrman
[not found] ` <2D51C7BA-FE51-48AF-9839-1A6AD2171510@bayour.com>
2010-09-25 2:18 ` Dave Chinner
1 sibling, 1 reply; 45+ messages in thread
From: Geoffrey Wehrman @ 2010-09-24 15:23 UTC (permalink / raw)
To: Turbo Fredriksson; +Cc: xfs
On Fri, Sep 24, 2010 at 04:07:23PM +0200, Turbo Fredriksson wrote:
| I started with a few hundred gig on my FS
| (on top of LVM which in turn is on top a bunch
| of MD devices).
|
| Slowly increasing the size with pvmove/{vg,lv}extend
| etc. Yesterday, I added more disks yet again and
| now have about 8Tb on one FS... ~1Tb free. But still
| get the 'No space left on device'.
|
|
| I've been looking through the 'Net and it
| must be because I'm out of inodes (and that
| the data is on the first 1Tb etc)...
You may may be able to workaround the the problem by increasing imaxpct
on the filesystem.
See http://oss.sgi.com/archives/xfs/2010-09/msg00295.html
| I'm running on AMD 64bit (native kernel, but
| Debian Lenny 32bit userland - 2.6.2[4-6] kernel).
|
|
|
| Now, if I use (I'll try to upgrade to a newer
| kernel so I can reverse) the inode64, what
| impact will this have? I guess I still have
| to move my firstly created 1Tb of-disk and
| then back again?
|
|
| The worst thing is that every time I grow
| the FS, I have to reboot into a 32bit kernel:
|
| xfs_growfs: XFS_IOC_FSGROWFSDATA xfsctl failed: Invalid argument
This may be becuase your are running 32bit userland.
| and then back to the 64bit kernel... How will
| this (system/FS) react if I go 64bit inodes?!
|
|
| And how safe is this!? I just don't have the
| possibility to do a full backup of all this
| data, not even temporarily... I _might_ be
| able to do this in a few weeks (work is ordering
| a bunch of LaCie 8Tb USB/eSATA storage boxes
| which I might be able to load for a few days
| 'to do some stress testing on' :)
|
|
| References:
| http://xfs.org/index.php/XFS_FAQ#Q:_Why_do_I_receive_No_space_left_on_device_after_xfs_growfs.3F
| http://xfs.org/index.php/XFS_FAQ#Q:_Can_I_just_try_the_inode64_option_to_see_if_it_helps_me.3F
| http://www.doc.ic.ac.uk/~dcw/xfs_16tb/
Once you have 64bit inodes, it is difficult to go back to 32bit inodes.
The filesystem will stay together, but you may not be able to access
your files with 64bit inodes from 32bit applications.
--
Geoffrey Wehrman
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: No space left on device
2010-09-24 14:07 No " Turbo Fredriksson
2010-09-24 15:23 ` Geoffrey Wehrman
@ 2010-09-25 2:18 ` Dave Chinner
1 sibling, 0 replies; 45+ messages in thread
From: Dave Chinner @ 2010-09-25 2:18 UTC (permalink / raw)
To: Turbo Fredriksson; +Cc: xfs
On Fri, Sep 24, 2010 at 04:07:23PM +0200, Turbo Fredriksson wrote:
> I started with a few hundred gig on my FS
> (on top of LVM which in turn is on top a bunch
> of MD devices).
>
> Slowly increasing the size with pvmove/{vg,lv}extend
> etc. Yesterday, I added more disks yet again and
> now have about 8Tb on one FS... ~1Tb free. But still
> get the 'No space left on device'.
>
>
> I've been looking through the 'Net and it
> must be because I'm out of inodes (and that
> the data is on the first 1Tb etc)...
>
> I'm running on AMD 64bit (native kernel, but
> Debian Lenny 32bit userland - 2.6.2[4-6] kernel).
....
> The worst thing is that every time I grow
> the FS, I have to reboot into a 32bit kernel:
>
> xfs_growfs: XFS_IOC_FSGROWFSDATA xfsctl failed: Invalid argument
The compat ioctl handlers for 32bit userspace to 64 bit kernel we
not included until a later kernel. Either upgrade to a 64 bit
userspace or to a much more recent kernel, and the problem will go
away.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 45+ messages in thread
* no space left on device
@ 2010-07-30 5:31 Lubos Kolouch
[not found] ` <AANLkTikBRfR45DZxZW9LM6wnREWrbysPCr9Z1d3YuYhC@mail.gmail.com>
0 siblings, 1 reply; 45+ messages in thread
From: Lubos Kolouch @ 2010-07-30 5:31 UTC (permalink / raw)
To: linux-btrfs
Hello,
kerner 2.6.35-rc6
btrfs filesystem df /home
Data: total=1.68TB, used=987.62GB
Metadata: total=56.01GB, used=48.16GB
System: total=12.00MB, used=200.00KB
touch: cannot touch `/home/x': No space left on device
Any ideas what I should do?
Thank you
Lubos
^ permalink raw reply [flat|nested] 45+ messages in thread
* No space left on device
@ 2008-12-08 9:46 Gabor MICSKO
2008-12-08 14:02 ` dcg
0 siblings, 1 reply; 45+ messages in thread
From: Gabor MICSKO @ 2008-12-08 9:46 UTC (permalink / raw)
To: linux-btrfs
hi,
I have an 80GB external HDD with one btrfs partition. Latest kernel
module and btrfs-progs from "unstable" git repos.
# mount
[...]
/dev/sdb1 on /media/coolermaster type btrfs (rw)
# df -h
[...]
/dev/sdb1 75G 61G 15G 81% /media/coolermaster
It seems like i have 15GB free space on the btrfs formatted partition,
but when i try to create a file of 4GB on the btrfs filesystem i get the
following error:
root@alderaan:/media/coolermaster/tmp# dd if=/dev/zero of=foobar.img
bs=1024 count=4000K
dd: writing `foobar.img': No space left on device
3372894+0 records in
3372893+0 records out
3453842432 bytes (3.5 GB) copied, 321.087 s, 10.8 MB/s
syslog:
Dec 8 10:35:46 alderaan kernel: [30716.434747] device fsid
46489b7e62f254e0-e306291dd7724d8f devid 1 transid 283 /dev/sdb1
Dec 8 10:35:50 alderaan kernel: [30720.457774] space info full 36
Am i missing something (e.g. reserved space for root, etc.) obvious
here?
Thanks,
--
mg
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: No space left on device
2008-12-08 9:46 No " Gabor MICSKO
@ 2008-12-08 14:02 ` dcg
0 siblings, 0 replies; 45+ messages in thread
From: dcg @ 2008-12-08 14:02 UTC (permalink / raw)
To: Gabor MICSKO; +Cc: linux-btrfs
El Mon, 08 Dec 2008 10:46:25 +0100, Gabor MICSKO <gabor.micsko@gmail.co=
m> escribi=C3=B3:
> # df -h
> [...]
> /dev/sdb1 75G 61G 15G 81% /media/coolermaster
>=20
> It seems like i have 15GB free space on the btrfs formatted partition=
,
> but when i try to create a file of 4GB on the btrfs filesystem i get =
the
> following error:
btrfs has an (artificial) limit of 85% of the space which won't be lift=
ed until
the allocation code is mature. So you can't use the 100% for now...that
--
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] 45+ messages in thread
* No space left on device
@ 2002-03-19 17:27 Sebastian
2002-03-20 17:27 ` David Woodhouse
0 siblings, 1 reply; 45+ messages in thread
From: Sebastian @ 2002-03-19 17:27 UTC (permalink / raw)
To: linux-mtd
Hi,
I'm trying to use JFFS2 on a 512K AMD (AM29F040B) flash chip (8 erase
blocks) installed on the IBM Walnut board. I was able to create a JFFS2
image with mkfs.jffs2, erase the flash, and then copy the image to the flash
( about 200 bytes). I can mount the mtdblock and browse the files on the
JFFS2 file system, but I cannot make any changes to the existing files or
add new ones. Everytime I try to modify it I get the 'No space left on
device' error. I had a quick look through the JFFS2 code and I see that
there has to be at least 5 free erase blocks (+ data) for the FS to function
properly ... but I have 8! I tried changing JFFS2_RESERVED_BLOCKS_BASE from
3 to 1 (which gives a total of 3 blocks for minimum requirement) and it
still didn't work. Am I missing something here? Do I have to pad my image
with 0xFF and make it 512K before I copy it? Is there another way to make
the image and copy it to the flash ... etc?
Regards,
Sebastian Vaitus
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: No space left on device
2002-03-19 17:27 Sebastian
@ 2002-03-20 17:27 ` David Woodhouse
2002-03-27 18:49 ` Sebastian
2002-03-27 19:13 ` David Woodhouse
0 siblings, 2 replies; 45+ messages in thread
From: David Woodhouse @ 2002-03-20 17:27 UTC (permalink / raw)
To: Sebastian; +Cc: linux-mtd
sebastian.vaitus@masstechgroup.com said:
> I was able to create a JFFS2 image with mkfs.jffs2, erase the flash,
> and then copy the image to the flash ( about 200 bytes). I can mount
> the mtdblock and browse the files on the JFFS2 file system, but I
> cannot make any changes to the existing files or add new ones.
> Everytime I try to modify it I get the 'No space left on device'
> error.
Please compile with CONFIG_JFFS2_FS_DEBUG=1, set the console loglevel to 9
so that you see all the KERN_DEBUG messages, and log the output over a
serial console while you reproduce this and also run 'df'.
--
dwmw2
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: No space left on device
2002-03-20 17:27 ` David Woodhouse
@ 2002-03-27 18:49 ` Sebastian
2002-03-27 19:13 ` David Woodhouse
1 sibling, 0 replies; 45+ messages in thread
From: Sebastian @ 2002-03-27 18:49 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-mtd
[-- Attachment #1: Type: text/plain, Size: 1288 bytes --]
David,
I have logged the output for the problem described in a previous email
(attached below). I am using 6 erase blocks this time instead of 8 (which
should still be enough for the 280 byte JFFS2 image). From what I saw in the
logs, I think that JFFS is only able to use the first block out of the 6 due
to some formatting or erasing problem with the rest of 5 blocks. Please have
a look at the attached log and maybe you'll be able to easily identify the
problem..
Regards,
Sebastian
>
> sebastian.vaitus@masstechgroup.com said:
> > I was able to create a JFFS2 image with mkfs.jffs2, erase the flash,
> > and then copy the image to the flash ( about 200 bytes). I can mount
> > the mtdblock and browse the files on the JFFS2 file system, but I
> > cannot make any changes to the existing files or add new ones.
> > Everytime I try to modify it I get the 'No space left on device'
> > error.
>
> Please compile with CONFIG_JFFS2_FS_DEBUG=1, set the console loglevel to 9
> so that you see all the KERN_DEBUG messages, and log the output over a
> serial console while you reproduce this and also run 'df'.
>
> --
> dwmw2
>
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
>
[-- Attachment #2: jffs2_clean --]
[-- Type: application/octet-stream, Size: 10013 bytes --]
*** Make the jffs2 image
root@192.0.0.123:/jffs2#
root@192.0.0.123:/jffs2# mkfs.jffs2 -d ./imgdir -o jffs2.img
root@192.0.0.123:/jffs2# ls
imgdir jffs2.img
root@192.0.0.123:/jffs2# ls -l
total 8
drwxr-xr-x 2 root root 4096 Mar 27 2002 imgdir
-rw-r--r-- 1 root root 280 Mar 27 2002 jffs2.img
*** Copy the image to flash
root@192.0.0.123:/jffs2# cd ..
root@192.0.0.123:/# cat /proc/mtd
dev: size erasesize name
mtd0: 00060000 00010000 "Flash File System"
mtd1: 00020000 00010000 "ROM Monitor"
mtd2: 00080000 00010000 "Whole Flash"
root@192.0.0.123:/# eraseall /dev/mtd0
MTD_open
MTD_ioctl
MTD_ioctl
Erasing 64 Kibytodo: 1 0 0 0
te @ 0 -- 0 % complete.MTD_ioctl
Erasing 64 Kibytodo: 1 0 0 0
te @ 10000 -- 16 % complete.MTD_ioctl
Erasing 64 Kibytodo: 1 0 0 0
te @ 20000 -- 33 % complete.MTD_ioctl
Erasing 64 Kibytodo: 1 0 0 0
te @ 30000 -- 50 % complete.MTD_ioctl
Erasing 64 Kibytodo: 1 0 0 0
te @ 40000 -- 66 % complete.MTD_ioctl
Erasing 64 Kibytodo: 1 0 0 0
te @ 50000 -- 83 % complete.MTD_close
Erased 384 Kibyte @ 0 -- 100% complete.
root@192.0.0.123:/# cp /jffs2/jffs2.img /dev/mtd0
MTD_open
MTD_write
MTD_close
*** Mount the JFFS2 file system
root@192.0.0.123:/# cd mnt/flash
root@192.0.0.123:/mnt/flash# ls
root@192.0.0.123:/mnt/flash# cd ..
root@192.0.0.123:/mnt# mount -t jffs2 /dev/mtdblock0 /mnt/flash
mtdblock_open
ok
jffs2: read_super for device 1f:00
jffs2_scan_eraseblock(): Scanning block at 0x0
jffs2_scan_inode_node(): Node at 0x00000000
jffs2_get_ino_cache(): ino 1
jffs2_get_ino_cache found 00000000 for ino 1
Allocated inocache at c778c2d4
jffs2_add_ino_cache: Add c778c2d4 (ino #1)
Node is ino #1, version 1. Range 0x0-0x0
jffs2_scan_dirent_node(): Node at 0x00000044
jffs2_get_ino_cache(): ino 1
jffs2_get_ino_cache found c778c2d4 for ino 1
jffs2_add_fd_to_list( c70124c0, c70124a0 (->00000000))
Dirent "test" (hash 0x01c4ddc5, ino #2
jffs2_scan_inode_node(): Node at 0x00000070
jffs2_get_ino_cache(): ino 2
jffs2_get_ino_cache found 00000000 for ino 2
Allocated inocache at c778c2c0
jffs2_add_ino_cache: Add c778c2c0 (ino #2)
Node is ino #2, version 1. Range 0x0-0x1d
jffs2_scan_inode_node(): Node at 0x000000d0
jffs2_get_ino_cache(): ino 2
jffs2_get_ino_cache found c778c2c0 for ino 2
Node is ino #2, version 2. Range 0x1d-0x1f
Found empty flash at 0x118
Empty flash detected from 0x00000118 to 0x00010000
Block at 0x00000000: free 0x0000fee8, dirty 0x00000000, used 0x00000118
jffs2_scan_eraseblock(): Scanning block at 0x10000
Found empty flash at 0x10000
Empty flash detected from 0x00010000 to 0x00020000
Block at 0x00010000: free 0x00010000, dirty 0x00000000, used 0x00000000
JFFS2: Erase block at 0x00010000 is not formatted. It will be erased
jffs2_scan_eraseblock(): Scanning block at 0x20000
Found empty flash at 0x20000
Empty flash detected from 0x00020000 to 0x00030000
Block at 0x00020000: free 0x00010000, dirty 0x00000000, used 0x00000000
JFFS2: Erase block at 0x00020000 is not formatted. It will be erased
jffs2_scan_eraseblock(): Scanning block at 0x30000
Found empty flash at 0x30000
Empty flash detected from 0x00030000 to 0x00040000
Block at 0x00030000: free 0x00010000, dirty 0x00000000, used 0x00000000
JFFS2: Erase block at 0x00030000 is not formatted. It will be erased
jffs2_scan_eraseblock(): Scanning block at 0x40000
Found empty flash at 0x40000
Empty flash detected from 0x00040000 to 0x00050000
Block at 0x00040000: free 0x00010000, dirty 0x00000000, used 0x00000000
JFFS2: Erase block at 0x00040000 is not formatted. It will be erased
jffs2_scan_eraseblock(): Scanning block at 0x50000
Found empty flash at 0x50000
Empty flash detected from 0x00050000 to 0x00060000
Block at 0x00050000: free 0x00010000, dirty 0x00000000, used 0x00000000
JFFS2: Erase block at 0x00050000 is not formatted. It will be erased
Scanned flash completely
Pass 1: ino #1
jffs2_build_inode building inode #1
jffs2_get_ino_cache(): ino 2
jffs2_get_ino_cache found c778c2c0 for ino 2
Increased nlink for child "test" (ino #2)
Pass 1: ino #2
jffs2_build_inode building inode #2
adding node 0000-001d @0x00000070 on flash, newfrag *c778b2d4
adding node 001d-001f @0x000000d0 on flash, newfrag *c778b2c0
j_a_f_d_t_f: skipping frag 0x0000-0x001d; phys 0x00000070 (*c778b2d4->00000000)
Pass 1 complete
Pass 2 (re)starting
Pass 2: ino #1, nlink 1, ic c778c2d4, nodes c778f360
Pass 2: ino #2, nlink 1, ic c778c2c0, nodes c778f340
Pass 2 complete
Pass 3: ino #1, ic c778c2d4, nodes c778f360
Pass 3: ino #2, ic c778c2c0, nodes c778f340
Pass 3 complete
jffs2_read_super(): Getting root inode
jffs2_read_inode(): inode->i_ino == 1
getting inocache
jffs2_get_ino_cache(): ino 1
jffs2_get_ino_cache found c778c2d4 for ino 1
jffs2_read_inode(): Got inocache at c778c2d4
jffs2_read_inode(): ino #1 nlink is 1
jffs2_get_inode_nodes(): ino #1
Node at 00000044 is a dirent node
Adding fd "test", ino #2
jffs2_add_fd_to_list( c70124e0, c7429c1c (->00000000))
Dirent "test" (hash 0x01c4ddc5, ino #2
Node at 00000000 is a data node
version 1, highest_version now 2
dnode @00000000: ver 1, offset 0000, dsize 0000
metadata @00000000: ver 1
jffs2_read_inode() returning
jffs2_read_super(): d_alloc_root()
JFFS2: Garbage collect thread is pid 186
thread_should_wake(): nr_free_blocks 0, nr_erasing_blocks 5, dirty_size 0x0
jffs2_garbage_collect_thread sleeping...
thread_should_wake(): nr_free_blocks 0, nr_erasing_blocks 5, dirty_size 0x0
Starting erase of pending block 0x00050000
Freeing all node refs for eraseblock offset 0x00050000
todo: 1 0 0 0
Erase at 0x00050000 finished, but state != MTD_ERASE_DONE. State is 0x0 instead.
Starting erase of pending block 0x00040000
Freeing all node refs for eraseblock offset 0x00040000
todo: 1 0 0 0
Erase at 0x00040000 finished, but state != MTD_ERASE_DONE. State is 0x0 instead.
Starting erase of pending block 0x00030000
Freeing all node refs for eraseblock offset 0x00030000
todo: 1 0 0 0
Erase at 0x00030000 finished, but state != MTD_ERASE_DONE. State is 0x0 instead.
Starting erase of pending block 0x00020000
Freeing all node refs for eraseblock offset 0x00020000
todo: 1 0 0 0
Erase at 0x00020000 finished, but state != MTD_ERASE_DONE. State is 0x0 instead.
Starting erase of pending block 0x00010000
Freeing all node refs for eraseblock offset 0x00010000
todo: 1 0 0 0
Erase at 0x00010000 finished, but state != MTD_ERASE_DONE. State is 0x0 instead.
jffs2_erase_pending_blocks completed
root@192.0.0.123:/mnt# thread_should_wake(): nr_free_blocks 0, nr_erasing_blocks 0, dirty_size 0x0
jffs2_erase_pending_blocks completed
*** List files on JFFS2 drive
root@192.0.0.123:/mnt# cd flash
root@192.0.0.123:/mnt/flash# ls
jffs2_readdir() for dir_i #1
Dirent 0: ".", ino #1
Dirent 1: "..", ino #1
Dirent 2: "test", ino #2, type 8
jffs2_readdir() for dir_i #1
Skipping dirent: "test", ino #2, type 8, because curofs 2 < offset 3
test
*** Attempt to rename the file under JFFS2
root@192.0.0.123:/mnt/flash# mv test test1
jffs2_lookup()
jffs2_lookup()
jffs2_read_inode(): inode->i_ino == 2
getting inocache
jffs2_get_ino_cache(): ino 2
jffs2_get_ino_cache found c778c2c0 for ino 2
jffs2_read_inode(): Got inocache at c778c2c0
jffs2_read_inode(): ino #2 nlink is 1
jffs2_get_inode_nodes(): ino #2
Node at 000000d0 is a data node
version 2, highest_version now 2
dnode @000000d0: ver 2, offset 001d, dsize 0002
Node at 00000070 is a data node
version 1, highest_version now 2
dnode @00000070: ver 1, offset 0000, dsize 001d
jffs2_add_full_dnode_to_inode(ino #2, f c6fd8b10, fn c778d360)
adding node 0000-001d @0x00000070 on flash, newfrag *c778b2c0
frag 0000-001d: 0x00000070 on flash (*c778b2c0->00000000)
jffs2_add_full_dnode_to_inode(ino #2, f c6fd8b10, fn c778d350)
adding node 001d-001f @0x000000d0 on flash, newfrag *c778b2d4
j_a_f_d_t_f: skipping frag 0x0000-0x001d; phys 0x00000070 (*c778b2c0->00000000)
frag 0000-001d: 0x00000070 on flash (*c778b2c0->c778b2d4)
frag 001d-001f: 0x000000d0 on flash (*c778b2d4->00000000)
Truncating fraglist to 0x0000001f bytes
jffs2_read_inode() returning
jffs2_reserve_space(): Requested 0x30 bytes
jffs2_reserve_space(): alloc sem got
Short on space, but total dirty size 0x00000000 < sector size 0x00010000, so -ENOSPC
jffs2_create()
jffs2_reserve_space(): Requested 0x44 bytes
jffs2_reserve_space(): alloc sem got
Short on space, but total dirty size 0x00000000 < sector size 0x00010000, so -ENOSPC
jffs2_create(): reserved 0xc7aef000 bytes
mv: cannot create regular file `test1': No space left on device
*** Attempt to change permissions on file
root@192.0.0.123:/mnt/flash# chmod 777 test
jffs2_setattr(): ino #2
jffs2_reserve_space(): Requested 0x44 bytes
jffs2_reserve_space(): alloc sem got
Short on space, but total dirty size 0x00000000 < sector size 0x00010000, so -ENOSPC
chmod: changing permissions of `test': No space left on device
*** Attempt to create a directory
root@192.0.0.123:/mnt/flash# mkdir test123
jffs2_lookup()
jffs2_reserve_space(): Requested 0x44 bytes
jffs2_reserve_space(): alloc sem got
Short on space, but total dirty size 0x00000000 < sector size 0x00010000, so -ENOSPC
mkdir: cannot create directory `test123': No space left on device
*** DF
root@192.0.0.123:/mnt/flash# df
Filesystem STATFS:
flash_size: 00060000
used_size: 00000118
dirty_size: 00000000
free_size: 0000fee8
erasing_size: 00000000
bad_size: 00050000
sector_size: 00010000
nextblock: 0x00000000
gcblock: NULL
clean_list: empty
dirty_list: empty
erasing_list: empty
erase_pending_list: empty
free_list: empty
bad_list: 00010000
bad_list: 00020000
bad_list: 00030000
bad_list: 00040000
bad_list: 00050000
bad_used_list: empty
1k-blocks Used Available Use% Mounted on
/dev/root 2869272 1721132 1002384 64% /
/dev/mtdblock0 384 384 0 100% /mnt/flash
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: No space left on device
2002-03-20 17:27 ` David Woodhouse
2002-03-27 18:49 ` Sebastian
@ 2002-03-27 19:13 ` David Woodhouse
2002-03-27 19:58 ` Sebastian
1 sibling, 1 reply; 45+ messages in thread
From: David Woodhouse @ 2002-03-27 19:13 UTC (permalink / raw)
To: Sebastian; +Cc: linux-mtd
sebastian.vaitus@masstechgroup.com said:
> Erase at 0x00010000 finished, but state != MTD_ERASE_DONE. State is
> 0x0 instead.
What hardware?
--
dwmw2
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: No space left on device
2002-03-27 19:13 ` David Woodhouse
@ 2002-03-27 19:58 ` Sebastian
0 siblings, 0 replies; 45+ messages in thread
From: Sebastian @ 2002-03-27 19:58 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-mtd
It's a 512K AMD flash with 8 erase blocks on an IBM Walnut board. The ROM
Monitor program which I use for booting takes up the last 2 blocks, and I'm
trying to use the first 6 blocks for JFFS.
I've attached a previous email below that gives more details.
Sebastian
Hi,
I'm trying to use JFFS2 on a 512K AMD (AM29F040B) flash chip (8 erase
blocks) installed on the IBM Walnut board. I was able to create a JFFS2
image with mkfs.jffs2, erase the flash, and then copy the image to the flash
( about 200 bytes). I can mount the mtdblock and browse the files on the
JFFS2 file system, but I cannot make any changes to the existing files or
add new ones. Everytime I try to modify it I get the 'No space left on
device' error. I had a quick look through the JFFS2 code and I see that
there has to be at least 5 free erase blocks (+ data) for the FS to function
properly ... but I have 8! I tried changing JFFS2_RESERVED_BLOCKS_BASE from
3 to 1 (which gives a total of 3 blocks for minimum requirement) and it
still didn't work. Am I missing something here? Do I have to pad my image
with 0xFF and make it 512K before I copy it? Is there another way to make
the image and copy it to the flash ... etc?
Regards,
Sebastian Vaitus
>
> sebastian.vaitus@masstechgroup.com said:
> > Erase at 0x00010000 finished, but state != MTD_ERASE_DONE. State is
> > 0x0 instead.
>
> What hardware?
>
> --
> dwmw2
>
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
>
^ permalink raw reply [flat|nested] 45+ messages in thread
end of thread, other threads:[~2014-02-12 11:08 UTC | newest]
Thread overview: 45+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-11-01 13:35 no space left on device Kenneth Johansson
2012-11-02 15:54 ` Kyle Gates
2012-11-02 15:59 ` Hugo Mills
2012-11-06 13:23 ` Kenneth Johansson
-- strict thread matches above, loose matches on Subject: below --
2014-02-12 9:51 No " Jakob Truelsen
2014-02-12 10:26 ` Hugo Mills
2014-02-12 10:45 ` Jakob Truelsen
2014-02-12 11:07 ` Hugo Mills
2014-02-12 10:34 ` Leonidas Spyropoulos
2012-08-03 10:05 no " Mark Marshall
2012-08-04 9:14 ` Chris Samuel
2012-08-04 9:26 ` Martin Steigerwald
2012-06-19 12:05 No " André Øien Langvand
2012-06-19 12:36 ` Geoffrey Wehrman
2012-06-20 6:07 ` Dave Chinner
2012-06-20 15:30 ` André Øien Langvand
[not found] <AANLkTinH225vC8fRbA7zk_iOEmyADFZMBS6b7gx1tOxm@mail.gmail.com>
2011-02-08 9:00 ` no " Leonidas Spyropoulos
2011-02-08 9:31 ` cwillu
2011-02-08 10:08 ` Leonidas Spyropoulos
2011-02-08 13:19 ` Helmut Hullen
2011-02-08 18:56 ` Erik Logtenberg
2011-02-08 19:43 ` Helmut Hullen
2011-02-12 14:11 ` Erik Logtenberg
2011-02-08 20:36 ` Helmut Hullen
2011-02-07 21:21 Leonidas Spyropoulos
2011-02-07 21:27 ` Erik Logtenberg
2011-02-07 23:58 ` Robert G.
2011-02-08 0:09 ` C Anthony Risinger
2010-09-24 14:07 No " Turbo Fredriksson
2010-09-24 15:23 ` Geoffrey Wehrman
[not found] ` <2D51C7BA-FE51-48AF-9839-1A6AD2171510@bayour.com>
[not found] ` <20100927160643.GA10594@sgi.com>
[not found] ` <D3DB5B56-D15C-408C-B2B4-58626C23D798@bayour.com>
2010-10-04 6:40 ` Turbo Fredriksson
2010-09-25 2:18 ` Dave Chinner
2010-07-30 5:31 no " Lubos Kolouch
[not found] ` <AANLkTikBRfR45DZxZW9LM6wnREWrbysPCr9Z1d3YuYhC@mail.gmail.com>
2010-07-30 12:27 ` Lubos Kolouch
[not found] ` <AANLkTinBj1O-LapAeBCT2Y3A1ZhfFZ3AotCk6SZ-e-2U@mail.gmail.com>
2010-07-30 14:30 ` Leonidas Spyropoulos
2010-07-30 15:02 ` Lubos Kolouch
2010-07-30 15:09 ` Lubos Kolouch
2010-08-14 20:15 ` Lubos Kolouch
2008-12-08 9:46 No " Gabor MICSKO
2008-12-08 14:02 ` dcg
2002-03-19 17:27 Sebastian
2002-03-20 17:27 ` David Woodhouse
2002-03-27 18:49 ` Sebastian
2002-03-27 19:13 ` David Woodhouse
2002-03-27 19:58 ` Sebastian
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.