Zach Brown wrote:
The second use case is to look at the physical layout of blocks on disk
for a specific file, use Mark Lord's write_long patches to inject a disk
error and then read that file to make sure that we are handling disk IO
errors correctly. A bit obscure, but really quite useful.
H
> The second use case is to look at the physical layout of blocks on disk
> for a specific file, use Mark Lord's write_long patches to inject a disk
> error and then read that file to make sure that we are handling disk IO
> errors correctly. A bit obscure, but really quite useful.
Hmm, yeah, th
Zach Brown wrote:
Can you clarify what you mean above with an example? I don't really
follow.
Sure, take 'tar' as an example. It'll read files in the order that
their names are returned from directory listing. This can produce bad
IO patterns because the order in which the file names are ret
> But, we shouldn't inflict all of this on fibmap/fiemapwe'll get
> lost trying to make the one true interface for all operations.
>
> For grouping operations on files, I think a read_tree syscall with
> hints for what userland will do (read, stat, delete, list
> filenames), and a better cook
> Can you clarify what you mean above with an example? I don't really
> follow.
Sure, take 'tar' as an example. It'll read files in the order that
their names are returned from directory listing. This can produce bad
IO patterns because the order in which the file names are returned
doesn't ma
On Oct 29, 2007 12:16 -0700, Mike Waychison wrote:
> Chris Mason wrote:
>> Reiserfs and Btrfs also use 0 to mean packed. It would be nice if there
>> was a way to indicate your-data-is-here-but-isn't-alone. But that's
>> more of a feature for the FIEMAP stuff.
>
> I hadn't heard of FIEMAP, so I
On Mon, 29 Oct 2007 12:18:22 -0700
Mike Waychison <[EMAIL PROTECTED]> wrote:
> Zach Brown wrote:
> >>> And another of my pet peeves with ->bmap is that it uses 0 to
> >>> mean "sparse" which causes a conflict on NTFS at least as block
> >>> zero is part of the $Boot system file so it is a real, va
Zach Brown wrote:
And another of my pet peeves with ->bmap is that it uses 0 to mean
"sparse" which causes a conflict on NTFS at least as block zero is
part of the $Boot system file so it is a real, valid block... NTFS
uses -1 to denote sparse blocks internally.
Reiserfs and Btrfs also use
Chris Mason wrote:
On Sat, 27 Oct 2007 18:57:06 +0100
Anton Altaparmakov <[EMAIL PROTECTED]> wrote:
Hi,
->bmap is ugly and horrible! If you have to do this at the very
least please cause ->bmap64 to be able to return error values in case
the file system failed to get the information or indeed
>> And another of my pet peeves with ->bmap is that it uses 0 to mean
>> "sparse" which causes a conflict on NTFS at least as block zero is
>> part of the $Boot system file so it is a real, valid block... NTFS
>> uses -1 to denote sparse blocks internally.
>
> Reiserfs and Btrfs also use 0
On Sat, 27 Oct 2007 18:57:06 +0100
Anton Altaparmakov <[EMAIL PROTECTED]> wrote:
> Hi,
>
> ->bmap is ugly and horrible! If you have to do this at the very
> least please cause ->bmap64 to be able to return error values in case
> the file system failed to get the information or indeed such
> info
Mike Waychison wrote:
The following series is meant to clean up FIBMAP paths with the eventual goal
of allowing users to be able to FIBMAP their data.
Keep in mind FIBMAP is currently extremely expensive on some
filesystems, e.g. ext3. Therefore, additional filesystem-level work
would have
On Sat, 27 Oct 2007, Anton Altaparmakov wrote:
> And another of my pet peeves with ->bmap is that it uses 0 to mean "sparse"
> which causes a conflict on NTFS at least as block zero is part of the $Boot
> system file so it is a real, valid block... NTFS uses -1 to denote sparse
> blocks internal
Hi,
->bmap is ugly and horrible! If you have to do this at the very least
please cause ->bmap64 to be able to return error values in case the
file system failed to get the information or indeed such information
does not exist as is the case for compressed and encrypted files for
example
The following series is meant to clean up FIBMAP paths with the eventual goal
of allowing users to be able to FIBMAP their data.
I'm sending this as an RFC as I've only tested this on a x86_64 kernel with a
32bit binary on ext2 and I've noticed a couple ext2_warnings already.
I'm unsure of the
15 matches
Mail list logo
