On 8/21/13 2:20 PM, Mark Tinguely wrote: > On 08/21/13 13:31, Eric Sandeen wrote: ... >>> There are different versions of XFS seek_data and they will >>> detect/report the start of data and holes differently so output >>> parsing will be a bear. The existing C code sends the 2 different >>> value numbers that could be reported. >> >> are they ... both correct? If one is a bug, it can just be a bug, right? >> I'm sorry I'm not up on the history. > > Lets say we have a file > hole 0-4K > data 4K-8K > hole 8-12K > data 12-16K > > for data/hole check starting at offset 0, valid response are > 0K or 4K for data > 0K or 16K or -1 for holes > > This feature and test was for Jeff fine-tuned seek_data/seek_hole support. The tests would be more specific to that feature and output is specific. Well, at least the man page says: > SEEK_DATA > Adjust the file offset to the next location in the file greater than > or equal to offset containing data. If offset points to data, then > the file offset is set to offset. So above, if we say "SEEK_DATA at offset 0" it seems like 0k is clearly wrong, and 4k is clearly right. > SEEK_HOLE > Adjust the file offset to the next hole in the file greater than or > equal to offset. If offset points into the middle of a hole, then the > file offset is set to offset. If there is no hole past offset, then > the file offset is adjusted to the end of the file (i.e., there is an > implicit hole at the end of any file). and "SEEK_HOLE at offset 0" should pretty clearly return 0, and 16k would be wrong. It's not POSIX yet, so I guess there's no gospel, but that's what the man page says. -Eric _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
