grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

ReiserFS reading performance patch


From: Albert Zeyer
Subject: ReiserFS reading performance patch
Date: Fri, 27 Apr 2012 16:05:35 +0200

Hi,

A while ago, I improved the grub-mount patches a bit. Mostly:

* Write a simplified compile.py script.
* Remove nested functions. They don't work on Mac because of stack
execution protection.
* Improve ReiserFS reading performance.

The whole fork:
https://github.com/albertz/grub-fuse

The full list of my changes:
https://github.com/albertz/grub-fuse/compare/35be80a3c6c0f1b9d56563221e17728151f51cbd...master

This is based on earlier work on grub-mount. I think that is all this:
https://github.com/albertz/grub-fuse/compare/f5d6558771f1ab2c8d324b23a5b2079a0dfb76a6...35be80a3c6c0f1b9d56563221e17728151f51cbd

I'm not sure wether any of this is of interest here. But maybe the
ReiserFS reading performance patch is, so some more details:

The reading performance was quite bad. Basically, the reading speed on
some position x in some file was linear(!) to x. Thus, reading a file
of length n is quadratic to n. With my patch, it is linear to n, as it
should be.

However, my patch is C++, so I'm not sure wether this is of interest.
Maybe something similar can be recoded in C.

The changes were just done in fs/reiserfs.c in grub_reiserfs_read.
Basically I added:
* _forward_optimal_position(key.directory_id, key.object_id,
initial_position, &current_position, &current_key_offset);
* _save_pos(key.directory_id, key.object_id, current_position,
current_key_offset);
https://github.com/albertz/grub-fuse/blob/master/grub-core/fs/reiserfs.c

The implementations of _forward_optimal_position and _save_pos:
https://github.com/albertz/grub-fuse/blob/master/grub-core/fs/reiserfs_key_cache.cpp

And the cache:
https://github.com/albertz/grub-fuse/blob/master/include/cache.h

I just needed this to grab some huge files from some ReiserFS usb disk
and it greatly helped me. The speed difference for files such as
1GB were *huge*: in the original implementation, it would have taken
about 10-20h, in my, it was about 20-30min.

Regards,
Albert



reply via email to

[Prev in Thread] Current Thread [Next in Thread]