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.
> 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,
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
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
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,
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.
> 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
> 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
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,
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
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
>> 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
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
>
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
information
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 to mean
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
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 0
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
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 went
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 cookie
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, valid
block...
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
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
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
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 internally.
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
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
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
30 matches
Mail list logo
