| |||||||||||||
Ts'o: Delayed allocation and the zero-length file problemTs'o: Delayed allocation and the zero-length file problemPosted Mar 13, 2009 20:28 UTC (Fri) by amk (subscriber, #19)In reply to: Ts'o: Delayed allocation and the zero-length file problem by dcoutts Parent article: Ts'o: Delayed allocation and the zero-length file problem
There's also the broken behaviour of the applications that are updating their config. files every minute, which shouldn't be forgotten. If saves are being explicitly requested by the user, that's pretty infrequent and the crash has to occur within a window of vulnerability, but constant resaves mean a crash will inevitably cause data loss.
(Log in to post comments)
Why this behavour is broken? It's perfectly normal behaviour... Posted Mar 14, 2009 11:10 UTC (Sat) by khim (subscriber, #9252) [Link] This P2P client. Good p2p client will keep information about peers for each file - this way if the the system is rebooted the lenghty process of finding peers can be avoided. Since there are hundreds (sometimes thousands) peers this means hundreds of files are rewritten every minute or so. If filesystem can not provide guarantees without fsync - I just refuse to use it. XFS went this way. XFS developers long argues their right to destroy files on crush and we've all agreed that they can do this and I can answer the question "What do you think about XFS?" with just "Don't use it. Ever." And everyone was happy. Looks like tytso actually fixed the problem in ext4 (even if actual words were akin "application developers are crazy and this is incorrect usage but we can not replace all of them") so at least I can conclude he's more sane then XFS developers...
|
|||||||||||||