xfs
[Top] [All Lists]

Re: [PATCH v5 0/10] fs: Introduce new flag(FALLOC_FL_COLLAPSE_RANGE) for

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH v5 0/10] fs: Introduce new flag(FALLOC_FL_COLLAPSE_RANGE) for fallocate
From: Hugh Dickins <hughd@xxxxxxxxxx>
Date: Wed, 26 Feb 2014 15:08:58 -0800 (PST)
Cc: Hugh Dickins <hughd@xxxxxxxxxx>, Namjae Jeon <linkinjeon@xxxxxxxxx>, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>, Matthew Wilcox <matthew@xxxxxx>, Theodore Ts'o <tytso@xxxxxxx>, Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx>, viro@xxxxxxxxxxxxxxxxxx, bpm@xxxxxxx, adilger.kernel@xxxxxxxxx, jack@xxxxxxx, mtk.manpages@xxxxxxxxx, lczerner@xxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx, linux-ext4@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, linux-mm@xxxxxxxxx, Namjae Jeon <namjae.jeon@xxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version:content-type; bh=X4hNcxWnM0+5nW6SBZZS87mbpsTR9vf490yhPRbd8/U=; b=dB6haGxvDIMk6Iaa6L21uZ+AIp4fmJE//eo7AUFMgBJunJIKKnzeob46VmATCCuVq0 IqKkbTBesUT6+y8dk7NUX4BjEIajzir/nnkm+u5f8vTSrukfIV9dgUcQ58ZqwGA3932i KByiki+1XFwIBdstOnehbNyBscOmiA1EUpv83w5xOg6v9TRhOFZgeDrkV1/7dWclVkBs 1h4qpc/GDiugFIP6KfFovMCMC6ylYqKeWyE1Z0DG885pj1dr0yspAexeeEjkiuVORd/U xdVaqXBWZMTPK3Lx2L8ThpbS3EKbslqa2u4H/uMQxuAIcYZDL3YPn6GI5RxNrMRQcGqu rmpw==
In-reply-to: <20140226064224.GU13647@dastard>
References: <1392741436-19995-1-git-send-email-linkinjeon@xxxxxxxxx> <20140224005710.GH4317@dastard> <20140225141601.358f6e3df2660d4af44da876@xxxxxxxxxxxxxxxx> <20140225041346.GA29907@dastard> <alpine.LSU.2.11.1402251217030.2380@xxxxxxxxxxxx> <20140226011347.GL13647@dastard> <alpine.LSU.2.11.1402251856060.1114@xxxxxxxxxxxx> <20140226064224.GU13647@dastard>
User-agent: Alpine 2.11 (LSU 23 2013-08-11)
On Wed, 26 Feb 2014, Dave Chinner wrote:
> On Tue, Feb 25, 2014 at 08:45:15PM -0800, Hugh Dickins wrote:
> > On Wed, 26 Feb 2014, Dave Chinner wrote:
> > > On Tue, Feb 25, 2014 at 03:23:35PM -0800, Hugh Dickins wrote:
> > > 
> > > > I should mention that when "we" implemented this thirty years ago,
> > > > we had a strong conviction that the system call should be idempotent:
> > > > that is, the len argument should indicate the final i_size, not the
> > > > amount being removed from it.  Now, I don't remember the grounds for
> > > > that conviction: maybe it was just an idealistic preference for how
> > > > to design a good system call.  I can certainly see that defining it
> > > > that way round would surprise many app programmers.  Just mentioning
> > > > this in case anyone on these lists sees a practical advantage to
> > > > doing it that way instead.
> > > 
> > > I don't see how specifying the end file size as an improvement. What
> > > happens if you are collapse a range in a file that is still being
> > > appended to by the application and so you race with a file size
> > > update? IOWs, with such an API the range to be collapsed is
> > > completely unpredictable, and IMO that's a fundamentally broken API.
> > 
> > That's fine if you don't see the idempotent API as an improvement,
> > I just wanted to put it on the table in case someone does see an
> > advantage to it.  But I think I'm missing something in your race
> > example: I don't see a difference between the two APIs there.
> 
> 
> Userspace can't sample the inode size via stat(2) and then use the value for a
> syscall atomically. i.e. if you specify the offset you want to
> collapse at, and the file size you want to have to define the region
> to collapse, then the length you need to collapse is (current inode
> size - end file size). If "current inode size" can change between
> the stat(2) and fallocate() call (and it can), then the length being
> collapsed is indeterminate....

Thanks for explaining more, I was just about to acknowledge what a good
example that is.  Indeed, it seems not unreasonable to be editing the
earlier part of a file while the later part of it is still streaming in.

But damn, it now occurs to me that there's still a problem at the
streaming end: its file write offset won't be updated to reflect
the collapse, so there would be a sparse hole at that end.  And
collapse returns -EPERM if IS_APPEND(inode).

Never mind, I'm not campaigning for a change of interface anyway.

Hugh

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