From: Jeff Mahoney <jeffm@suse.com>
To: melodramus@online.de
Cc: reiserfs-devel@vger.kernel.org
Subject: Re: (nearly) full hd causes weird and corrupting behaviour of apps and tools
Date: Thu, 22 Apr 2010 15:10:21 -0400 [thread overview]
Message-ID: <4BD09F1D.5020700@suse.com> (raw)
In-Reply-To: <20100419220453.5af4ab06.melodramus@online.de>
-----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-----
next prev parent reply other threads:[~2010-04-22 19:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-19 15:02 (nearly) full hd causes weird and corrupting behaviour of apps and tools melodramus
2010-04-19 18:14 ` Jeff Mahoney
2010-04-19 20:04 ` melodramus
2010-04-22 19:10 ` Jeff Mahoney [this message]
2010-04-22 0:05 ` melodramus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BD09F1D.5020700@suse.com \
--to=jeffm@suse.com \
--cc=melodramus@online.de \
--cc=reiserfs-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.