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 _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
