David Chinner wrote:
Using a new API for new functionality is a bad thing?
if existing API can be used ...
No, it doesn't provide the same functionality.
Firstly, XFS attaches a different I/O completion to delalloc writes
to allow us to update the file size when the write is beyond the
Jeff Garzik wrote:
Alex Tomas wrote:
So without the ability to attach specific I/O completions to bios
or support for unwritten extents directly in __mpage_writepage,
there is no way XFS can use this generic delayed allocation code.
I didn't say generic, see Subject: :)
Well, it shouldn't
David Chinner wrote:
Firstly, XFS attaches a different I/O completion to delalloc writes
to allow us to update the file size when the write is beyond the
current on disk EOF. This code cannot do that as all it does is
allocation and present normal looking buffers to the generic code
path.
how
On Fri, Jul 27, 2007 at 08:29:31AM +0530, Aneesh Kumar K.V wrote:
What are the issues you see with PATCH 1 and PATCH 2 which implement
Undo I/O Manager and undoe2fs other than it is not hooked into any of
the existing tools. I will try to add it to mke2fs as you suggested. But
should that
On Fri, 2007-07-27 at 13:16 +0800, Yan Zheng wrote:
Hi, all
I think I found a bug in ext4/extents.c, ext4_ext_put_in_cache uses
__u32 to receive physical block number. ext4_ext_put_in_cache is
used in ext4_ext_get_blocks, it sets ext4 inode's extent cache
according most recently tree
Alex Tomas wrote:
So without the ability to attach specific I/O completions to bios
or support for unwritten extents directly in __mpage_writepage,
there is no way XFS can use this generic delayed allocation code.
I didn't say generic, see Subject: :)
Well, it shouldn't even be in the VFS
Theodore Tso wrote:
On Fri, Jul 27, 2007 at 08:29:31AM +0530, Aneesh Kumar K.V wrote:
What are the issues you see with PATCH 1 and PATCH 2 which implement
Undo I/O Manager and undoe2fs other than it is not hooked into any of
the existing tools. I will try to add it to mke2fs as you
