kconfig's file handling (was: XFS: how to NOT null files on fsck?)
A message that is not in the archive (sent off-list or not yet received): [email protected]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 4 lines · Oswald Buddenhagen
heya,
read the attachement first (put on your asbestos underwear first ;). not exactly news to me, but somehow i never got to fixing it ...
There is nothing to fix, we already use a tempfile + rename, it's in KSaveFile since 1999. Or just look with strace if you don't believe me. This Tim Connors guy shouldn't talk about things he obviously knows nothing about.
As far as I can see the problem is that the filesystem writes out the meta data before the actual file data hits the disk which creates a period of time in which the on-disk state of the filesystem contains trashed files. I believe ReiserFS actually has an option to do things in a sane order so that it doesn't trash recently used files on an unclean shutdown.
The sentiment among filesystem developers seem to be that they don't care if they trash files as long as the filesystem itself remains in a consistent state. This kind of dataloss is the result of that attitude, either go complain with them if it bothers you, or use a filesystem that does it right.
Cheers,
Waldo
- --
[email protected] | KDE Community World Summit 2004 | [email protected] [email protected] | 21-29 August, Ludwigsburg, Germany | [email protected]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQFA89YvN4pvrENfboIRAptaAJ9YBv63UUL7Elcl3QsjYJPbGche7wCdEzKr Y+I4Kyi+p+r/gPixNdXQphE=
=c3HD
-----END PGP SIGNATURE-----
Quoted 4 lines · Waldo Bastian
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1On Tue July 13 2004 13:05, Oswald Buddenhagen wrote:
Quoted 8 lines
Quoted 4 lines
heya,
read the attachement first (put on your asbestos underwear first ;). not exactly news to me, but somehow i never got to fixing it ...
There is nothing to fix, we already use a tempfile + rename, it's in KSaveFile since 1999. Or just look with strace if you don't believe me. This Tim Connors guy shouldn't talk about things he obviously knows nothing about.
Sorry, I'm just basing the above on my *experience* with trying to unfsck 3 different peoples kde settings when the nfs server went down.
And since it was a controlled shutdown, there would have been no cache worries, and the fact the kde corrupted itself points to having problems within kde, not problems within a fs or nfs.
Quoted 5 lines
As far as I can see the problem is that the filesystem writes out the meta data before the actual file data hits the disk which creates a period of time in which the on-disk state of the filesystem contains trashed files. I believe ReiserFS actually has an option to do things in a sane order so that it doesn't trash recently used files on an unclean shutdown.
Well, no other program I have ever used, which does the tempfile+rename thing, has ever failed on me.
Signature · 4 lines
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
-o)
/\\ The penguins are coming...
_\_v the penguins are coming...Quoted 3 lines · Waldo Bastian
There is nothing to fix, we already use a tempfile + rename, it's in KSaveFile since 1999.
oh, indeed. i didn't dig deep enough. sorry for the noise. the symlink case is handled differently, though (and it falls back to in-place rewriting too early - the symlink target could be potentially handled without in-place rewriting as well). consequently the paragraph about in-place rewriting is valid, even if it is only a border case.
another thing to consider is a complete audit of kde regarding the creation of files; i'm sure not everybody uses KSaveFile or equivalent code. no, i don't volunteer. :}
Quoted 5 lines
As far as I can see the problem is that the filesystem writes out the meta data before the actual file data hits the disk which creates a period of time in which the on-disk state of the filesystem contains trashed files.
yup
Quoted 3 lines
I believe ReiserFS actually has an option to do things in a sane order so that it doesn't trash recently used files on an unclean shutdown.
not only reiserfs.
Quoted 6 lines
The sentiment among filesystem developers seem to be that they don't care if they trash files as long as the filesystem itself remains in a consistent state. This kind of dataloss is the result of that attitude, either go complain with them if it bothers you, or use a filesystem that does it right.
the code is there, the additional integrity just doesn't come for free, so it's disabled by default.
greetings
Signature · 3 lines
Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done.
Quoted 6 lines · Waldo Bastian
The sentiment among filesystem developers seem to be that they don't care if they trash files as long as the filesystem itself remains in a consistent state. This kind of dataloss is the result of that attitude, either go complain with them if it bothers you, or use a filesystem that does it right.
Ext3 with ordered writes (the default) gets this right.
Unfortunately, cheating can give you better benchmark resuls, and some people seem to care more about better benchmark results than silly things like user's files not getting wiped. For many workloads, especially for user desktops, the disk bandwidth isn't saturated, and given that most writes are asynchronous in nature, a faster write benchmark for a particular filesystem or filesystme mode may not translate into a user-visible difference. So focusing on improved write speeds at the cost of data robustness can very often be false economy.
- Ted
Quoted 4 lines · Waldo Bastian
There is nothing to fix, we already use a tempfile + rename, it's in KSaveFile since 1999. Or just look with strace if you don't believe me. This Tim Connors guy shouldn't talk about things he obviously knows nothing about.
How about fsync on the tempfile before the rename? Without getting into a religious discussion about whether or not this should be necessary, it will certainly help in many cases.
Quoted 3 lines
This kind of dataloss is the result of that attitude, either go complain with them if it bothers you, or use a filesystem that does it right.
I'm not sure people can just change their fs, some people have no options and for some platforms where KDE is used there might not be any alternatives. I really think fsync here would help in most if not all of those cases and it shouldn't adversely affect the performance (to the best of my knowledge KDE doesn't update dotfiles all that often and they are pretty small). Other applications do this already and it seems to be very reliable for them.
--cw
P.S. I'm a bit confused as to why files get smashed on ENOSPC and when
NFS servers croak though.