Recent Features
| |||||||||||||
Shared painShared painPosted Feb 9, 2012 17:37 UTC (Thu) by khim (subscriber, #9252)In reply to: Shared pain by dlang Parent article: XFS: the filesystem of the future?
Exactly. This is part of the very simple proof sequence. Fact 1: any application which calls fsync is very slow in ext3. You've just observed it. Yes, it's not fair to XFS. No, I don't think being fair is guaranteed in real world.
(Log in to post comments)
Shared pain Posted Feb 9, 2012 19:26 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
sorry, on my systems I'm not willing to tolerate a 50x slowdown just to make badly written apps be a little less likely to be confused after a power outage.
and I think that advocating that you have the right to make this choice for everyone else is going _way_ too far.
when I have applications that loose config data after a problem happens (which isn't always a system crash, apps that have this sort of problem usually have it after the application crashes as well), my solution is backups of the config (idealy into something efficient like git), not crippling the rest of the system to band-aid the bad app.
Shared pain Posted Feb 9, 2012 20:44 UTC (Thu) by Wol (guest, #4433) [Link]
And what is "badly written" about an app that expects the computer to do what was asked of it?
I know changing things around for the sake of it doesn't matter when everything goes right, but if I tell the computer "do this, *then* that, *followed* by the other", well, if I told an employee to do it and they did things in the wrong order and screwed things up as a *direct* *result* of messing with the order, they'd get the sack.
The only reason we're in this mess, is because the computer is NOT doing what the programmer asked. It thinks it knows better. And it screws up as a result.
And the fix isn't that hard - just make sure you flush the data before the metadata (or journal the data too), which is pretty much (a) sensible, and (b) what every user would want if they knew enough to care.
Cheers,
Shared pain Posted Feb 9, 2012 20:52 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
it is badly written because you did not tell the computer that you wanted to make sure that the data was written to the drive in a particular order.
If the system does not crash, the view of the filesystem presented to the user is absolutely consistent, and the rename is atomic.
The problem is that there are a lot of 'odd' situations that you can have where data is written to a file while it is being renamed that make it non-trivial to "do the right thing" because the system is having to guess at what the "right thing" is for this situation.
try running a system with every filesystem mounted with the sync option, that will force the computer to do exactly what the application programmers told it to do, writing all data exactly when they tell it to, even if this means writing the same disk sector hundreds of times as small writes happen. The result will be un-usable.
so you don't _really_ want the computer doing exactly what the programmer tells it to, you only want it to do so some of the time, not the rest of the time.
Shared pain Posted Feb 9, 2012 21:13 UTC (Thu) by khim (subscriber, #9252) [Link] so you don't _really_ want the computer doing exactly what the programmer tells it to, you only want it to do so some of the time, not the rest of the time. Sure. YMMV as I've already noted. Good filesystem for USB sticks must flush on close(2) call. Good general purpose filesystem must guarantee rename(2) atomicity in the face of system crash. You can use whatever you want for your own system - it's you choice. But when question is about replacement of extX… it's other thing entirely. To recommend filesystem which likes to eat user's data is simply irresponsible.
Shared pain Posted Feb 14, 2012 16:16 UTC (Tue) by nye (guest, #51576) [Link]
>when I have applications that loose config data after a problem happens (which isn't always a system crash, apps that have this sort of problem usually have it after the application crashes as well)
That can't possibly be the case. You must be talking about applications which do something like truncate+rewrite, which is entirely orthogonal to the discussion (and is pretty clearly a bug).
I suspect you haven't understood the issue at hand.
|
|||||||||||||