-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/19/2010 04:04 PM, melodramus@xxxxxxxxx wrote: > On Mon, 19 Apr 2010 14:14:47 -0400 > Jeff Mahoney <jeffm@xxxxxxxx> 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----- -- To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
