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 17:30:35 -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=dUzj4Nr6xrOmftiyQvLfKgaS4Ts2Hf+tW5mL2EYNXXY=; b=olsjWQt1deveuzDVERTImjqLdj0vsRH0p9lIrMChc85doy1cSZLkWDs1+ZXCNmooG7 lobc+mWdqwVbQYmYF/iW7KmAs2JTgsaRaRWKdeSRoAM9I7IM/ECl72+DESGXTHaRHx5M Bq4z/XsSBXaOJd7ysm0j/0TeQOEkvnIQ5Du0h6plNzfcGoptfqXFiAKuVNq30P8xAB2T AnZewjD4Dyx5hxy3xAQXc9JVbVUkCNsWQA+vZjdy40fQXRDutAbvDUzxXYW1us7OH7V9 YLKdsUftDudPqIqvvP4nMrRwuLglrNKF9IFA3lTZQ4l9/phOh0pvgIYQexWWYVqRhdge Azng==
In-reply-to: <20140227012431.GW13647@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> <alpine.LSU.2.11.1402261454270.2808@xxxxxxxxxxxx> <20140227012431.GW13647@dastard>
User-agent: Alpine 2.11 (LSU 23 2013-08-11)
On Thu, 27 Feb 2014, Dave Chinner wrote:
> On Wed, Feb 26, 2014 at 03:08:58PM -0800, Hugh Dickins wrote:
> > 
> > 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).
> 
> Well, we figure that most applications won't be using append only
> inode flags for files that they know they want to edit at random
> offsets later on. ;)
> 
> However, I can see how DVR apps would use open(O_APPEND) to obtain
> the fd they write to because that sets the write position to the EOF
> on every write() call (i.e. in generic_write_checks()). And collapse
> range should behave sanely with this sort of usage.
> 
> e.g. XFS calls generic_write_checks() after it has taken the IO lock
> to set the current write position to EOF. Hence it will be correctly
> serialised against collapse range calls and so O_APPEND writes will
> not leave sparse holes if collapse range calls are interleaved with
> the write stream....

Right, I was getting confused between O_APPEND and APPEND_Only!
Thanks, I'm back to being convinced by your example.

Hugh

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