This seems like iteration 66 of the ill fated mobling readahead crap.
Please go to linux-fsdevel to define a proper interface instead of
your per-filesystem hacks. I had hoped Arjan got it after the last big
flameware, but it seems like you're only moving from one target to the
next.
NACK in
On 7/19/2010 1:03 AM, Christoph Hellwig wrote:
This seems like iteration 66 of the ill fated mobling readahead crap.
I think you need to actually look at what this patch does before
rendering this judgment; something you apparently have not done.
--
To unsubscribe from this list: send
On Mon, Jul 19, 2010 at 07:00:33AM -0700, Arjan van de Ven wrote:
On 7/19/2010 1:03 AM, Christoph Hellwig wrote:
This seems like iteration 66 of the ill fated mobling readahead crap.
I think you need to actually look at what this patch does before
rendering this judgment; something you
On Wed, Jul 14, 2010 at 04:26:45PM +0800, Shaohua Li wrote:
On Wed, Jul 14, 2010 at 04:02:16PM +0800, Shaohua Li wrote:
Hi,
We have file readahead to do asyn file read, but has no metadata
readahead. For a list of files, their metadata is stored in fragmented
disk space and metadata
Hi,
We have file readahead to do asyn file read, but has no metadata
readahead. For a list of files, their metadata is stored in fragmented
disk space and metadata read is a sync operation, which impacts the
efficiency of readahead much. The patches try to add meatadata readahead
for btrfs.
In
On Wed, Jul 14, 2010 at 04:02:16PM +0800, Shaohua Li wrote:
Hi,
We have file readahead to do asyn file read, but has no metadata
readahead. For a list of files, their metadata is stored in fragmented
disk space and metadata read is a sync operation, which impacts the
efficiency of readahead
