From: "Brian J. Tarricone", Date: 15/03/2009 07:31
> That sounds pretty awful, to me, to be honest. So every FS -- no, wait
> -- every FS that's going to be pushed as a "mainstream" FS -- is going
> to have to be closely monitored to make sure it doesn't have this
> behavior? Everyone's going to b
Morten Welinder wrote:
This is crazy.
People are actually advocating that thousands upon thousands of applications
need to be changed.
No. The crazy part is that people care so much at all. Nobody cared a
year ago - why care today?
This isn't a *new* problem in any way.
The question as
On Sat, 14 Mar 2009 20:10:32 -0400 Morten Welinder wrote:
> This is crazy.
>
> People are actually advocating that thousands upon thousands of
> applications need to be changed.
If they're behaving incorrectly, yes.
But I don't think most of them are. The only case where *not* doing an
fsync()
This is crazy.
People are actually advocating that thousands upon thousands of applications
need to be changed.
Yes, POSIX allows this particular idiotic behaviour. So what? It probably also
allows free() to do nothing, yet no-one in their right mind would want that. Or
maybe you would be upse
Alexander Larsson wrote:
On Sat, 2009-03-14 at 13:38 -0400, Mark Mielke wrote:
Should sed -i use fsync()? If it
is promising atomic-change-in-place, then it certainly should.
This is the same kind of reasoning that says its ok to do something
because its specified by posix. If its not
Alexander Larsson wrote:
On Sat, 2009-03-14 at 19:21 +0100, Alexander Larsson wrote:
We all understand that its is per-spec to not guarantee
data-before-metadata on rename, we're not stupid and able to read a
manpage as well as you. But we still think its a bad idea and not a sign
of robust s
On Sat, 14 Mar 2009 13:16:45 +0100 Alexander Larsson wrote:
> On Fri, 2009-03-13 at 14:34 -0700, Brian J. Tarricone wrote:
> I think you are conflating two issues.
No, I don't think I am. I think I'm just replying to a subset of the
email that's slightly off topic. Or rather, the fact that I'
On Sat, 2009-03-14 at 19:21 +0100, Alexander Larsson wrote:
> We all understand that its is per-spec to not guarantee
> data-before-metadata on rename, we're not stupid and able to read a
> manpage as well as you. But we still think its a bad idea and not a sign
> of robust software.
Additionally
On Sat, 2009-03-14 at 13:38 -0400, Mark Mielke wrote:
> Should sed -i use fsync()? If it
> is promising atomic-change-in-place, then it certainly should.
This is the same kind of reasoning that says its ok to do something
because its specified by posix. If its not defined somewhere that sed -i
m
Alexander Larsson wrote:
2) such filesystems are broken
Clearly the answer to 1 is yes. Anything else would be a disservice to
our users data. However, that doesn't mean such filesystems aren't
broken, in the sense that I would never let a filesystem like that near
any of my data.
For instance,
On Fri, 2009-03-13 at 14:34 -0700, Brian J. Tarricone wrote:
>
> > Now, we don't actually really need the data to be on the disk at a
> > certain time. On the contrary, its really fine if its delayed. But, what
> > we want is either the old file in place, or the new file in place, not
> > the old
On Fri, 2009-03-13 at 18:20 -0600, Federico Mena Quintero wrote:
> On Fri, 2009-03-13 at 22:16 +0100, Alexander Larsson wrote:
>
> > Its well explained in the various discussions about this. Essentially,
> > the metadata for the rename is written to disk, but the data in the file
> > is not (yet,
12 matches
Mail list logo
