xfs
[Top] [All Lists]

Re: [PATCH] xfsprogs: add fpunch command for hole punching via fallocate

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH] xfsprogs: add fpunch command for hole punching via fallocate
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 19 Jan 2011 08:23:03 +1100
Cc: Josef Bacik <josef@xxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <20110118131203.GA4349@xxxxxxxxxxxxx>
References: <1295009545-17839-1-git-send-email-josef@xxxxxxxxxx> <20110118125112.GB21440@xxxxxxxxxxxxx> <20110118130603.GA23491@xxxxxxxxxxxxxxxxxxxxxxxxxx> <20110118131203.GA4349@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.20 (2009-06-14)
On Tue, Jan 18, 2011 at 08:12:03AM -0500, Christoph Hellwig wrote:
> On Tue, Jan 18, 2011 at 08:06:03AM -0500, Josef Bacik wrote:
> > Sounds good.  So which do we want, a new command or a new flag?  Thanks,
> 
> I'll wait for dave to chime in.  I think we should absolutely expose
> it as a fallocate flag, but if there's a good reason we can also expose
> it as a separate command.

My reasoning was that:

        a) it is consistent with other xfs_io allocation manipulation
           command structures such as resvsp/unresvsp
        b) "punch" is less to type than "fallocate -p"
        c) self documenting in scripts e.g. -c "punch 4k 4k" is much
           more obvious than -c "fallocate -p 4k 4k" and saves a man
           page lookup when reading the script.
        d) punch as a top level command will show up in the "xfs_io
           -c help", not require you to know it is a suboption of the
           "falloc" command to find out how to use it.
        e) the xfs_io command does not have to have the same name
           and structure as the underlying API that implements the
           functionality the commands execute.


Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>