This is a test to make sure seek_data/seek_hole is acting like it does on Solaris. It will check to see if the fs supports finding a hole or not and will adjust as necessary. Signed-off-by: Josef Bac
So I just looked at this with an eye to validating an XFS implementation, and I came up with this list of stuff that the test does not cover that I'd need to test in some way: - files with clean unwr
The discussion leading up to the resurrection of SEEK_HOLE/SEEK_DATA was pretty much about that point. The conclusion based on the Sun documentation and common sense was that SEEK_DATA may only consi
There is the argument, that if this interface can distinguish these dirty unwritten extents, then why can't the fiemap interface too? The advantage of the fiemap interface is that it can distinguish
On 06/29/2011 02:53 AM, Dave Chinner wrote: On Tue, Jun 28, 2011 at 11:33:19AM -0400, Josef Bacik wrote: This is a test to make sure seek_data/seek_hole is acting like it does on Solaris. It will che
On 06/29/2011 12:40 AM, Christoph Hellwig wrote: On Wed, Jun 29, 2011 at 04:53:07PM +1000, Dave Chinner wrote: On Tue, Jun 28, 2011 at 11:33:19AM -0400, Josef Bacik wrote: This is a test to make sure
On 06/29/2011 03:42 AM, Pádraig Brady wrote: There is the argument, that if this interface can distinguish these dirty unwritten extents, then why can't the fiemap interface too? The advantage of the
On 06/29/2011 10:36 AM, Christoph Hellwig wrote: On Wed, Jun 29, 2011 at 10:29:02AM -0700, Sunil Mushran wrote: I'm not too sure about that. Atleast not enabled by default. Most users use cp to backu
That's a fair point. On the other hand if you wanted to start working with the backup copy, you might want it allocated to avoid fragmentation and ENOSPC issues. What we were going with was empty ->
That brings us back to square one. FIEMAP is supposed to tell you about the physical layout on disk. Unwritten extents physically always are there, but whether they might have to be copied depends en
Can you resend this with any updates that happened in the meantime? Dave also still had some comments about semantics, so it might be worth to incorporate that as well.
The main questions I had when looking at this was how we should handle unwritten extents - the only answer I got was along the lines of "we'll deal with that once filesystems have implemented somethi
Let's first clarify what you mean by an unwritten extent? Do you mean a preallocated extent that returns 0 when read, or do you mean a delayed allocation extent that was written by the application th
Exactly that. That's not an unwritten extent - that's a delayed allocation extent ;) OK, that's the way I'd expect to treat both preallocated and delalloc space. Agreed, that's the way I'd interpret
Author: Marco Stornelli <marco.stornelli@xxxxxxxxx>
Date: Fri, 26 Aug 2011 08:24:45 +0200
2011/8/26 Dave Chinner <david@xxxxxxxxxxxxx>: No for me. A hole is made up of zero data? It's a strange definition for me. A hole is simply no data. With this definition a hole can be start from a bl
It's a very natural definition for me. It mirrors the behaviour of read() of sparse data inside i_size that file system authors already have to consider. It's also a reminder for people that this in
Author: Marco Stornelli <marco.stornelli@xxxxxxxxx>
Date: Sat, 27 Aug 2011 10:30:32 +0200
Il 26/08/2011 16:41, Zach Brown ha scritto: Hole: a range of the file that contains no data or is made up entirely of NULL (zero) data. Holes include preallocated ranges of files that have not had ac
Author: Marco Stornelli <marco.stornelli@xxxxxxxxx>
Date: Sun, 28 Aug 2011 12:17:36 +0200
Il 27/08/2011 10:30, Marco Stornelli ha scritto: Il 26/08/2011 16:41, Zach Brown ha scritto: Hole: a range of the file that contains no data or is made up entirely of NULL (zero) data. Holes include