Re: Performance issue when trashing files (backtraced to fsync)

[Alexander Larsson <alexl redhat com>]

On Tue, 2009-08-11 at 23:38 +0200, Xavier Bestel wrote:
> Le mardi 11 août 2009 à 19:54 +0200, Alexander Larsson a écrit :
> > On Tue, 2009-08-11 at 17:55 +0200, Xavier Bestel wrote:
> > > I don't know how standardized the trash "protocol" is, but maybe one
> > > keyfile by deleted file is too much. Some kind of batching would be
> > > good.
> > 
> > Its a freedesktop standard, and furthermore the creation of the file is
> > used for atomicity guarantees, so hard to change. Anyway, there are not
> > normally that many files, if you e.g. trash a folder there will just be
> > one info file for all that.
> 
> You can't atomically create a keyfile and move a file, there's a window
> between the two. So you can have a state (e.g. after a crash) where the
> keyfile exists and the file isn't moved (or the other way around, I
> didn't look at the code).

Of course that is not atomic, and thats not what its used for either.
What is atomic is the creation of the info file, and thus the selection
of the name of the trashed file in the trash directory (the name of the
trashed file is based on the info file name). So, if two processes trash
a file called "foobar" (in different directories, ending up in the same
trash dir) then the result is two files in the trash dir with different
names, not one overwriting the other.

If there is an info file without the corresponding actual file that is
not such a big problem really, you don't lose any data, it just looks
like there is an empty file in the trash or something.

> I suppose what must be guaranteed is something like the keyfile is
> commited to disk before the file is moved.

Thats not really super that important. Having a broken info file in some
edge case is not a gigantic problem, it will just lose the original
name/location and the trash time. Things should still work.