On Tue, Jul 20, 2004 at 04:44:21AM +0100, Ricardo Correia wrote:
> Well, out of 10 crashes, at least 9 times I lose a file..
this at some level becomes a religious debate between "bad fs" and
"badly behaved application"
ignoring the fact that there were no "good fs's" two years ago and
many people still have to use 'bad fs'
> In 2 days I've lost all my aMule downloads and configuration, most
> of my KDE configuration (several times)
KDE is known to be bad here, there is a trivial fix the KDE people
could make but they basically said "use a better fs" or something
silly (by sane fs they seem to mean ext3 and that's not an option for
many many people, all the world is not Linux, etc).
> The thing I'm trying to understand is why does this happen with XFS?
> I know it can happen with any filesystem, but the fact is that it
> doesn't happen nearly as many times as it does with XFS.
ext3 by default shouldn't show this. ext2 probably will, not sure
about others
XFS *might* be worse than others because of delay allocations, i'm
still mulling that over at to how much difference that should make
> Well, for example, the aMule program uses a small file called
> xxx.part.met to track downloaded parts, which usually has about
> 200-800 bytes. I tried to use the trick you mentioned (chattr +S,
> if I'm not mistaken) with these files, because these were the ones
> which after the reboot became 0-length.
maybe aMule writes a new file and renames? that would certainly cause
problems
> The problem is that after about a minute or so, lsattr shows that
> the file doesn't have the attribute anymore. So I suppose these
> files gets deleted and recreated every so often.
sounds like it. which is lame, because if aMule is doing that it
could fsync the new file before the rename and you wouldn't have any
problems
> So does this really happen because XFS only journals metadata?
yes
> From what I understand, XFS puts small files inside the inode, when
> it fits (ls -sh shows 0 KB used).
only metadata, file data cannot put be into the inode no matter how
small it is
> Or does XFS truncate the file immediately on-disk after unlink()? I
> don't think that makes much sense.
sounds like:
old file foo on disk, all safe
new file bar is written metadata on disk, file
data in ram
[*]
rename bar to foo old file unlinked, new
file in place but data
not flushed yet
now, if there was an fsync at [*] it would work just fine
> So why does this happen? Is it for security reasons? I don't think
> it's that..
it is
> there are lots of single-user systems out there which don't need
> that. Or is it really by design? Can't it be changed (optionally,
> if you must)?
no, because the data was never flushed to disk, so changing the
behavior won't help you there --- since there is no data to access if
you did it differently
> I think the 'chattr +S', even if it works for whole directories,
> cannot be the solution for this.
for the most part at works, but in truth for many application it
papers of the problem and could still have nasty consequences
ideally well written applications doesn't have this problem, but once
again we just get into some religious discussion about what an fs
should do and what it shouldn't do, etc. and how much more clueless we
want to allow application writers to be
--cw
|