coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: making a file sparse - in-place?


From: Rodrigo Campos
Subject: Re: making a file sparse - in-place?
Date: Fri, 24 Jan 2014 13:38:55 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

On Fri, Jan 24, 2014 at 12:49:18PM +0000, Pádraig Brady wrote:
> On 01/24/2014 03:56 AM, Rodrigo Campos wrote:
> > On Fri, Jan 24, 2014 at 03:30:20AM +0000, Pádraig Brady wrote:
> >> On 01/24/2014 03:12 AM, Rodrigo Campos wrote:
> >>> On Fri, Jan 24, 2014 at 02:59:41AM +0000, Pádraig Brady wrote:
> >>>> On 01/24/2014 02:41 AM, Rodrigo Campos wrote:
> >>>>> On Fri, Jan 24, 2014 at 01:07:21AM +0000, Pádraig Brady wrote:
> >>>>>> On 01/24/2014 12:47 AM, Bernhard Voelker wrote:
> >>>>>>> Inspired by a recent post on util-linux ML [1], talking about turning
> >>>>>>> a file into a sparse file in-place, i.e. not using a 2-step approach
> >>>>>>> like `cp --sparse file file2 && mv file2 file`), I thought, hey, don't
> >>>>>>> we have this in coreutils already?
> 
> > But it's just a matter of policy. Do you know what the policy is ?
> 
> We use system specific functionality where appropriate.
> We would just decide what to do when the current
> file doesn't support punch hole (which we have to do anyway as said above).
> Do we fail or ignore. Generally sparse requests are advisory,
> and indeed in dd we already quietly disable sparse mode if not supported.
> So we would do the same if punch hole was not supported on the dest.

Ohh, okay!

> >> If there are other methods to punch a hole in a file
> >> on other systems, they can be added as an option to coreutils
> >> without changing the interface.
> > 
> > AFAIK, there aren't. And, as I said, is not linux specific only, it also is 
> > fs
> > specific.
> 
> There is fcntl(F_FREESP) on solaris, with mention of porting that to FREEBSD.

Ohh, nice. I didn't know about them!

> > If I have to guess, this flag is like other useful flags linux adds and most
> > other platforms don't. So you are exposing a feature here, that will only 
> > will
> > work on linux with certain filesystems. Probably there is a policy already
> > esablished for this ? (I mean, if it's ok or not)
> 
> If there is a sensible fall back, then it's OK to use non ubiquitous 
> interfaces.

Great!




Thanks a lot, and sorry for all the emails :)
Rodrigo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]