(nearly) full hd causes weird and corrupting behaviour of apps and tools

(nearly) full hd causes weird and corrupting behaviour of apps and tools

[melodramus]

am not shure if i'm right here. i'm still using reiserfs on my root partition and detected strange behaviour when the partition is believed to be 100% full by the system (namely df, though there may still be a hundred megs available.) because of the widespread disorientation of tools and apps i believe that the fs-driver is not telling the truth about the available physical space.

lots of apps get into trouble, loose their states or configure widgets wrong. for example, sylpheed can't check against certificate servers anymore, the firefox download dialog can't list new entries but downloads them in background while halting complete downloads on their last few seconds and refusing to restart or delete the entries. this could all be just the apps but even the system tools behave strange. i copied an old backup cd to a new backup hd, grabbing the iso and loop-mounting it on the hd for faster access. at some point, tools showed up wrong information. df even showed old information about previous mounts from where ever it got that back. i detected that the system log has grown to about hundred megs because of lots of usb events (for the backup hd.) after having deleted th
 e logfile, df even showed less available memory than before (some kb.) mount refused to unmount partitions, which caused me to restart the system.

in the new session df showed about 143 MB of free space for the root partition. things seemed to work again but, though the iso loop-mounted fine, i wasn't able to read files from it anymore because of io-errors all through (the next iso worked fine.) seems that mount has even scratched this iso. this is why i believe that the current situation is really dangerous, though a full root partition is possibly not that common.

MeloDramus <melodramus@online.de>

Re: (nearly) full hd causes weird and corrupting behaviour of apps and tools

[Jeff Mahoney]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/19/2010 11:02 AM, melodramus@online.de wrote:
> am not shure if i'm right here. i'm still using reiserfs on my root partition and detected strange behaviour when the partition is believed to be 100% full by the system (namely df, though there may still be a hundred megs available.) because of the widespread disorientation of tools and apps i believe that the fs-driver is not telling the truth about the available physical space.
> 
> lots of apps get into trouble, loose their states or configure widgets wrong. for example, sylpheed can't check against certificate servers anymore, the firefox download dialog can't list new entries but downloads them in background while halting complete downloads on their last few seconds and refusing to restart or delete the entries. this could all be just the apps but even the system tools behave strange. i copied an old backup cd to a new backup hd, grabbing the iso and loop-mounting it on the hd for faster access. at some point, tools showed up wrong information. df even showed old information about previous mounts from where ever it got that back. i detected that the system log has grown to about hundred megs because of lots of usb events (for the backup hd.) after having deleted 
 the logfile, df even showed less available memory than before (some kb.) mount refused to unmount partitions, which caused me to restart the system.
> 
> in the new session df showed about 143 MB of free space for the root partition. things seemed to work again but, though the iso loop-mounted fine, i wasn't able to read files from it anymore because of io-errors all through (the next iso worked fine.) seems that mount has even scratched this iso. this is why i believe that the current situation is really dangerous, though a full root partition is possibly not that common.

Deleting the log file isn't enough. You need to restart syslog. The file
can't really be deleted until all open references of it are gone.

As for having space free but unable to use it, please attach the output
of debugreiserfs -o <dev>

I've seen it happen before where a file system becomes badly fragmented
enough that new objectids can't be represented in the objectid map at
the start of the file system.

- -Jeff

- -- 
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iEYEARECAAYFAkvMnZcACgkQLPWxlyuTD7LMDQCfcYCjdCqMbeIiazMHxP+21ivR
TosAniEoVhaUvz/YSipik7XeoqQY8hwE
=znYQ
-----END PGP SIGNATURE-----

Re: (nearly) full hd causes weird and corrupting behaviour of apps and tools

[melodramus]

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

On Mon, 19 Apr 2010 14:14:47 -0400
Jeff Mahoney <jeffm@suse.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> Deleting the log file isn't enough. You need to restart syslog. The file
> can't really be deleted until all open references of it are gone.
> 
> As for having space free but unable to use it, please attach the output
> of debugreiserfs -o <dev>
> 
> I've seen it happen before where a file system becomes badly fragmented
> enough that new objectids can't be represented in the objectid map at
> the start of the file system.

makes me wonder if apps can trust the posix interfaces in case a reiserfs is fragmented badly. will write() write to nil, and is fsync() reliable?

> 
> - -Jeff

attached are the files before and after reiserfschk


MeloDramus <melodramus@online.de>

[-- Attachment #2: text --]
[-- Type: plain/text, Size: 2439 bytes --]

[-- Attachment #3: text2 --]
[-- Type: plain/text, Size: 2720 bytes --]

Re: (nearly) full hd causes weird and corrupting behaviour of apps and tools

[melodramus]

just wanted to add that i just detected a broken reiserfs on one of my partitions. this is the first time since i use reiserfs (about eight years now!) there's something really wrong with it.


On Mon, 19 Apr 2010 17:02:23 +0200
melodramus@online.de wrote:

> am not shure if i'm right here. i'm still using reiserfs on my root partition and detected strange behaviour when the partition is believed to be 100% full by the system (namely df, though there may still be a hundred megs available.) because of the widespread disorientation of tools and apps i believe that the fs-driver is not telling the truth about the available physical space.
> 
> lots of apps get into trouble, loose their states or configure widgets wrong. for example, sylpheed can't check against certificate servers anymore, the firefox download dialog can't list new entries but downloads them in background while halting complete downloads on their last few seconds and refusing to restart or delete the entries. this could all be just the apps but even the system tools behave strange. i copied an old backup cd to a new backup hd, grabbing the iso and loop-mounting it on the hd for faster access. at some point, tools showed up wrong information. df even showed old information about previous mounts from where ever it got that back. i detected that the system log has grown to about hundred megs because of lots of usb events (for the backup hd.) after having deleted 
 the logfile, df even showed less available memory than before (some kb.) mount refused to unmount partitions, which caused me to restart the system.
> 
> in the new session df showed about 143 MB of free space for the root partition. things seemed to work again but, though the iso loop-mounted fine, i wasn't able to read files from it anymore because of io-errors all through (the next iso worked fine.) seems that mount has even scratched this iso. this is why i believe that the current situation is really dangerous, though a full root partition is possibly not that common.
> 
> MeloDramus <melodramus@online.de>


MeloDramus <melodramus@online.de>

Re: (nearly) full hd causes weird and corrupting behaviour of apps and tools

[Jeff Mahoney]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/19/2010 04:04 PM, melodramus@online.de wrote:
> On Mon, 19 Apr 2010 14:14:47 -0400
> Jeff Mahoney <jeffm@suse.com> wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>> Deleting the log file isn't enough. You need to restart syslog. The file
>> can't really be deleted until all open references of it are gone.
>>
>> As for having space free but unable to use it, please attach the output
>> of debugreiserfs -o <dev>
>>
>> I've seen it happen before where a file system becomes badly fragmented
>> enough that new objectids can't be represented in the objectid map at
>> the start of the file system.
> 
> makes me wonder if apps can trust the posix interfaces in case a reiserfs is fragmented badly. will write() write to nil, and is fsync() reliable?

It's not an issue of fragmentation in the normal sense - it's an issue
of objectid fragmentation. Once an objectid is released, it can be
reclaimed. Fragmentation in the tree isn't an issue - it's just the map
that represents the allocations that can be an issue. There are just
certain cases - and I've only seen this in the wild exactly once - where
a heavy create-delete load in a pattern I haven't been able to reproduce
will cause the map to need more space than allotted to represent it.

Even if this were to occur, fsync() and write() are still reliable. It
will just return -ENOSPC when there is clearly space available.

> attached are the files before and after reiserfschk

Ok, thanks. They don't exhibit the problem I was thinking of.

- -Jeff
- -- 
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iEYEARECAAYFAkvQnx0ACgkQLPWxlyuTD7JauwCgmgNAckDBOyWxKafX7QCh4275
FXAAniASL6yiubjOywq/tAddLPn6Znsv
=rpQ7
-----END PGP SIGNATURE-----