[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1355162759.2704.50.camel@menhir>
Date: Mon, 10 Dec 2012 18:05:59 +0000
From: Steven Whitehouse <swhiteho@...hat.com>
To: "Theodore Ts'o" <tytso@....edu>
Cc: Dave Chinner <david@...morbit.com>,
Chris Mason <chris.mason@...ionio.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Ric Wheeler <rwheeler@...hat.com>,
Ingo Molnar <mingo@...nel.org>,
Christoph Hellwig <hch@...radead.org>,
Martin Steigerwald <Martin@...htvoll.de>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH, 3.7-rc7, RESEND] fs: revert commit bbdd6808 to
fallocate UAPI
Hi,
On Mon, 2012-12-10 at 12:37 -0500, Theodore Ts'o wrote:
> On Sat, Dec 08, 2012 at 11:17:05AM +1100, Dave Chinner wrote:
> > I wouldn't recommend XFS_IOC_ALLOCSP as a user-friendly interface.
> > The concept, however, implemented by a new fallocate()
> > flag (say FALLOC_FL_WRITE_ZEROS) so that the filesystem knows that
> > the application considers unwritten extents undesirable is exactly
> > the sort of thing that we should be considering implementing.
>
> What's the point of using a new flag like this (or XFS's
> XFS_IOC_ALLOCSP) for writing zeros during preallocation as oppoised to
> simply doing a fallocate() followed by zeroing the data via a O_DIRECT
> write system call?
>
If the block device can zero out blocks more efficiently than just
writing zeros (i.e. via sb_issue_zeroout()) then this could be faster.
In fact GFS2 already zeros out fallocate()d extents in this way because
it has no way to mark unwritten extents in its metadata, and we did not
want to leave them uninitialised,
Steve.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists