A little background information: Note that the below discussion is mostly academic on *BSD unless you have mariginal hardware; the filesystem code does careful ordering of metadata updates unless the user explicitly turns the ordering off. Thus, you will only see this error if you have mariginal hardware or are running an FS you have explicitly decided you can gamble with.
Linux and traditional *BSD has choosen different policies here; Linux somewhat gambles with the users data and security setup as a tradeoff for faster metadata updates and lower code complexity. This tradeoff is probably OK if you're only going to use it on a normal workstation, without any critical data on it; I guess it can be OK in some server apps too (though I wouldn't do it). *BSD does things "by the book", guaranteeing metadata integrity (and thus avoiding data leaks, and keeping POSIX semantics for e.g. rename). Note that the traditional BSD tradeoff is NOT the same as Linux 'sync'.
The latest development on the BSD side of this is "soft updates", which is safe without the speed penalty.
Now, back to the original poster:
"Deleting is the default action on the *BSD fsck" Oh yeah, I didn't really want those files. They take up too much space anyway. After fsck destroys my data I will have room for more!
I'll take "maybe corrupt" over "kiss your files goodbye" for sure.
We're not talking "Maybe corrupt". We're talking of at least one file being corrupt, and we're talking of the possibility of private data crossing the protection domain between user IDs, and of wrong data or code migrating into setuid programs.
For some applications, it might be an OK tradeoff to silently corrupt one file to potentially make another file OK. However, it is not OK for any of my applications - I need to know that the security policies for files are held; if I can't know this, I want to restore from backup, rather than keep running with corrupt files.
Note that I'm a FreeBSD person; all of this from theory, as I've not run Linux for anything serious for a couple of years.
If you run this using the default parameters and get an unplanned shutdown (crash, power outage, whatever), you are likely to get minor file corruption. To get correct behaviour, you should mount the filesystem in sync mode, and rely on the underlying RAID setup to handle write caching if you need it (as this remove one failure layer).
You will also want to modify e2fsck to avoid silent data corruption. e2fsck will (or would, the last time I was in a discussion with the author on these issues) handle a block that is shared between two files by duplicating the block. This silently corrupts at least one file. You will probably want to change it to delete both files, possibly making that an interactive question. (Deleting is the default action on the *BSD fsck, BTW).
Slashdot Mirror
Linux and traditional *BSD has choosen different policies here; Linux somewhat gambles with the users data and security setup as a tradeoff for faster metadata updates and lower code complexity. This tradeoff is probably OK if you're only going to use it on a normal workstation, without any critical data on it; I guess it can be OK in some server apps too (though I wouldn't do it). *BSD does things "by the book", guaranteeing metadata integrity (and thus avoiding data leaks, and keeping POSIX semantics for e.g. rename). Note that the traditional BSD tradeoff is NOT the same as Linux 'sync'.
The latest development on the BSD side of this is "soft updates", which is safe without the speed penalty.
Now, back to the original poster:
"Deleting is the default action on the *BSD fsck" Oh yeah, I didn't really want those files. They take up too much space anyway. After fsck destroys my data I will have room for more!
I'll take "maybe corrupt" over "kiss your files goodbye" for sure.
We're not talking "Maybe corrupt". We're talking of at least one file being corrupt, and we're talking of the possibility of private data crossing the protection domain between user IDs, and of wrong data or code migrating into setuid programs.
For some applications, it might be an OK tradeoff to silently corrupt one file to potentially make another file OK. However, it is not OK for any of my applications - I need to know that the security policies for files are held; if I can't know this, I want to restore from backup, rather than keep running with corrupt files.
Eivind.
Note that I'm a FreeBSD person; all of this from theory, as I've not run Linux for anything serious for a couple of years.
If you run this using the default parameters and get an unplanned shutdown (crash, power outage, whatever), you are likely to get minor file corruption. To get correct behaviour, you should mount the filesystem in sync mode, and rely on the underlying RAID setup to handle write caching if you need it (as this remove one failure layer).
You will also want to modify e2fsck to avoid silent data corruption. e2fsck will (or would, the last time I was in a discussion with the author on these issues) handle a block that is shared between two files by duplicating the block.
This silently corrupts at least one file. You will probably want to change it to delete both files, possibly making that an interactive question. (Deleting is the default action on the *BSD fsck, BTW).
Eivind.