On Fri, 26 Feb 2016 22:00:44 +0100, Stanislav Brabec said:
> Well, it seems to be safe, even if the loop device was not allocated by
> mount(8) itself, as
> ioctl(fd, LOOP_CLR_FD)
> never returns EBUSY:
The fact you don't get an EBUSY doesn't mean it's actually safe
pgpySWEpuLcwi.pgp
Descr
On Thu, 22 Sep 2011 18:45:56 PDT, H Hartley Sweeten said:
> Quiet the sparse noise:
>
> warning: symbol '__lookup_extent_mapping' was not declared. Should it be
> static?
Patch itself is correct, changelog is bad. You're not quieting sparse noise,
you're making a declaration static because it d
On Wed, 04 May 2011 13:58:39 EDT, Josef Bacik said:
> +#define SEEK_HOLE3 /* seek to the closest hole */
> +#define SEEK_DATA4 /* seek to the closest data */
Comments here need nearest/next fixing as well - otherwise the ext[34] crew may
actually implement the commented semant
On Wed, 04 May 2011 15:10:20 EDT, Josef Bacik said:
> Yeah sorry the log says "nearest" but the code says "next", if you look
> at it thats how it works. Thanks,
Oh good - the changelog is usually easier to fix than the code is. :)
Probably want to fix the changelog before it gets committed, a
On Wed, 04 May 2011 13:58:39 EDT, Josef Bacik said:
> -SEEK_HOLE: this moves the file pos to the nearest hole in the file from the
> given position.
Nearest, or next? Solaris defines it as "next", for a good reason - otherwise
you can get stuck in a case where the "nearest" hole is back towards
On Thu, 21 Apr 2011 15:42:33 EDT, Josef Bacik said:
> -SEEK_HOLE: this moves the file pos to the nearest hole in the file from the
> given position.
Do we want the semantic to be "the nearest" hole? Or did we really want "the
next" hole? Loops like a bullet loaded in the chamber and pointed at
On Sun, 05 Dec 2010 08:24:32 EST, Theodore Tso said:
> I've been using a kernel which is between 2.6.37-rc2 and -rc3 with a LUKS /
> dm-crypt / LVM / ext4 setup for my primary file systems, and I haven't
> observed
> any corruption for the last two weeks or so.
Pretty much exactly the same setup
On Fri, 09 Jan 2009 08:34:57 PST, "H. Peter Anvin" said:
> A lot of noise is being made about the naming of the levels (and I
> personally believe we should have a different annotation for "inline
> unconditionally for correctness" and "inline unconditionally for
> performance", as a documentation
