On 08/27/2011 01:30 AM, Marco Stornelli wrote:
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 actual data written to them.
No for me. A hole
On 08/25/2011 06:35 PM, Dave Chinner wrote:
Agreed, that's the way I'd interpret it, too. So perhaps we need to
ensure that this interpretation is actually tested by this test?
How about some definitions to work by:
Data: a range of the file that contains valid data, regardless of
whether it
On 8/30/2011 8:29 PM, Dave Chinner wrote:
And that's -exactly- the ambiguous, vague definition that has raised
all these questions in the first place. I was in doubt about whether
unwritten extents can be considered a hole, and by your definition
that means it should be data. But Andreas seems
On 08/20/2011 09:32 AM, Marco Stornelli wrote:
Il 20/08/2011 17:36, Sunil Mushran ha scritto:
On 08/20/2011 03:03 AM, Marco Stornelli wrote:
Il 20/08/2011 11:41, Marco Stornelli ha scritto:
Hi,
Il 28/06/2011 17:33, Josef Bacik ha scritto:
This just gets us ready to support the SEEK_HOLE
On 08/22/2011 03:56 AM, Marco Stornelli wrote:
2011/8/22 Sunil Mushransunil.mush...@oracle.com:
On 08/20/2011 09:32 AM, Marco Stornelli wrote:
Thank. Yes the word next is not very clear. I re-read the proposal for
the standard, actually it's seems to me that if we are in the last hole we
On 08/22/2011 10:56 AM, Marco Stornelli wrote:
Il 22/08/2011 17:57, Sunil Mushran ha scritto:
The following test was used to test the early implementations.
http://oss.oracle.com/~smushran/seek_data/
Thank you very much!! I found another point. Your test fails with my
implementation
On 08/20/2011 03:03 AM, Marco Stornelli wrote:
Il 20/08/2011 11:41, Marco Stornelli ha scritto:
Hi,
Il 28/06/2011 17:33, Josef Bacik ha scritto:
This just gets us ready to support the SEEK_HOLE and SEEK_DATA flags.
Turns out
using fiemap in things like cp cause more problems than it solves,
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 seek_data/seek_hole is acting like it does on
Solaris. It will check to see if the fs
On 05/19/2011 04:05 AM, Christoph Hellwig wrote:
On Wed, May 18, 2011 at 07:44:44PM -0700, Sunil Mushran wrote:
Unwritten (preallocated) extents are considered holes because the file system
treats reads to such regions in the same way as it does to holes.
How does this work for the case
On 05/19/2011 02:13 AM, Tristan Ye wrote:
+ if (inode-i_size == 0 || *offset= inode-i_size) {
+ ret = -ENXIO;
+ goto out_unlock;
+ }
Why not using if (*offset= inode-i_size) directly?
duh!
+ BUG_ON(cpos le32_to_cpu(rec.e_cpos));
On 05/05/2011 01:16 PM, Josef Bacik wrote:
This is my very rough tester for testing seek_hole/seek_data. Please look over
it and make sure we all agree that the semantics are correct. My btrfs patch
passes with this and ext3 passes as well. I still have to added fallocate() to
it, but for now
On 04/22/2011 04:50 AM, Eric Blake wrote:
That blog also mentioned the useful idea of adding FIND_HOLE and
FIND_DATA, not implemented in Solaris, but which could easily be
provided as additional lseek constants in Linux to locate the start of
the next chunk without repositioning and which could
On 04/22/2011 09:40 AM, Eric Blake wrote:
On 04/22/2011 10:28 AM, Sunil Mushran wrote:
while(1) {
read(block);
if (block_all_zeroes)
lseek(SEEK_DATA);
}
What's wrong with the above? If this is the case, even SEEK_HOLE
is not needed but should be added as it is already
On 04/22/2011 10:03 AM, Eric Blake wrote:
cp can read whatever blocksize it chooses. If that block contains
zero, it would signal cp that maybe it should SEEK_DATA and skip
reading all those blocks. That's all. We are not trying to achieve
perfection. We are just trying to reduce cpu waste.
If
On 04/22/2011 01:10 PM, Jonathan Nieder wrote:
Hi,
Josef Bacik wrote:
This just gets us ready to support the SEEK_HOLE and SEEK_DATA flags. Turns out
using fiemap in things like cp cause more problems than it solves, so lets try
and give userspace an interface that doesn't suck. So we have
On 04/22/2011 11:06 AM, Andreas Dilger wrote:
Sure, there are lots of wasted syscalls, but in this case the cost of doing
extra SEEK_DATA and SEEK_HOLE operations may be fairly costly. This involves
scanning the whole disk layout, possibly over a network, which might need tens
or hundreds of
On 04/21/2011 01:45 PM, Theodore Tso wrote:
On Apr 21, 2011, at 3:42 PM, Josef Bacik wrote:
+ case SEEK_DATA:
+ case SEEK_HOLE:
+ return -EINVAL;
}
Maybe we should be returning EOPNOTSUPP?
-- Ted
For SEEK_HOLE yes. But we could let the default SEEK_DATA be
Frankly I see no point extending the ioctl interface when we have
a syscall interface.
On 03/31/2011 12:33 AM, Tristan Ye wrote:
We're currently support two paths from VFS to preallocate unwritten
extents(from FS_IOC_RESVSP, or fallocate()), likewise, behavior of
punching-hole should be treated
18 matches
Mail list logo
