| View previous topic :: View next topic |
| Author |
Message |
Kaapeli
Tux's lil' helper
Joined: 27 Dec 2004
Posts: 110
Location: Oulu, Finland
|
 Posted: Sat Apr 30, 2005 11:29 am Post subject: Reiser4: Do It Yourself -repacker |
 |
|
Based on my experiences, reiser4 is a great filesystem but like every other filesystems, the performance will detoriate after using it long enough. More details about my thoughts can be read from here . The repacker is supposed to optimize the filesystem structures and make it fast again. Unfortunately, repacker is not a vailable yet. Well, I made a simple script which is supposed to increase the performance on reiser4 partitions.
WARNING - Do not use this script unless you know what you're doing
Now you're warned, I don't take any responsibility what my script might do to your system, so don't use it  Actually I haven't even used it on my main root partition yet. I used my old fragmented root partition for testing and benchmarking.
Here is the magic script:
| Code: |
for i in * ; do echo "$i" && cp -a "$i" "$i".back && rm -rf "$i" && mv "$i".back "$i" ; done
|
What it does is simply to copy the object (file or directory) with a new name and remove the original copy, then rename the new object so it has the same name as the old copy. Doing that allows reiser4 to write the directory contents again to the disk and pack it tightly again. After running this script, the contents and the attributes of the files should be the same. Only bug I can see is that the directory modification time doesn't remain the same. If you have a solution for this (possibly using tar instead of cp), let me know about it. The only scenario when this script can increase performance is when a directory is been in use for a long perioid of time and there have been a lot of (small) modifications. Basically it should make the directory as fast as it used to be when you first created it.
Well, then for the benchmarks.. My old root partition was badly fragmented and had very poor performance with it. I tested this script on usr/lib directory. This test measures how long it took to read the contents of the directory before any modifications.
| Code: |
# mount oldroot/
# time tar -cf /dev/zero oldroot/usr/lib/
real 0m50.784s
user 0m0.251s
sys 0m3.949s
# umount oldroot/ && mount oldroot/
# time tar -cf /dev/zero oldroot/usr/lib/
real 0m50.840s
user 0m0.188s
sys 0m3.965s
|
Not very good time, there was only 608 MB files on the directory. Average transfer rate was 11.9 MB/s. I know the disk is capable to read ~50 MB/s when reading large sequential files.
Then I ran the magic script:
| Code: |
# cd oldroot/usr/lib
# for i in * ; do echo "$i" && cp -a "$i" "$i".back && rm -rf "$i" && mv "$i".back "$i" ; done
|
And then another benchmark after the script had finished:
| Code: |
# cd ../../..
# umount oldroot/ && mount oldroot/
# time tar -cf /dev/zero oldroot/usr/lib/
real 0m22.767s
user 0m0.197s
sys 0m3.900s
# umount oldroot/ && mount oldroot/
# time tar -cf /dev/zero oldroot/usr/lib/
real 0m22.984s
user 0m0.193s
sys 0m3.832s
|
Data read time dropped 55%, average transfer rate was 26.7 MB/s. I think this is a significant improvement. It still doesn't give maximum throughput from the disk, but it's much better. I think the free space on that partition is quite fragmented too.
But this script has also some drawbacks:
- Directory modification times will not remain the same. This may or may not cause problems, I don't know.
- Inode numbers change (original file is deleted and an identical file is created). It a file is in use while this script accesses it, there may be some unwanted side effects.
- If the script is used in a directory which contains large subdirectories, large amount of free space is required.
- Something else I'm not aware of.
I would like to hear your comments about this method of increasing disk performance on reiser4 partitions. I think this is more "an ugly hack" than a real defragmenter or repacker, but it seems to do rather good job when used on a fragmented directory.
Mods, if you have a better forum for this thread, feel free to move it 
_________________
Temperatures |
|
| Back to top |
|
 |
Maedhros
Bodhisattva
Joined: 14 Apr 2004
Posts: 5511
Location: Durham, UK
|
| Posted: Sat Apr 30, 2005 1:47 pm Post subject: Re: Reiser4: Do It Yourself -repacker |
|
|
| Kaapeli wrote: | | Mods, if you have a better forum for this thread, feel free to move it |
Ok.
Moved from Other Things Gentoo.
_________________
No-one's more important than the earthworm. |
|
| Back to top |
|
|
Tiger683
Veteran
Joined: 08 Jan 2005
Posts: 1347
Location: Heffner's House
|
| Posted: Sat Apr 30, 2005 3:56 pm Post subject: |
|
|
A better bet would be to use
and
inbetween just rm -Rf ./* on the partition (or directory)
fragmentation of freespace drops to 0 then, well, disregarding reiser4 flaws that is....
cheers
T
PS:
no , i didnt test it and i never will 
_________________
Retired gentoo user |
|
| Back to top |
|
|
rmh3093
Advocate
Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY
|
| Posted: Sat Apr 30, 2005 4:34 pm Post subject: |
|
|
is there any word yet when reiser4.1 will be out, i need that repacker, lol
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger. |
|
| Back to top |
|
|
wishkah
Guru
Joined: 09 May 2003
Posts: 441
Location: de
|
| Posted: Sat Apr 30, 2005 4:35 pm Post subject: |
|
|
Hm, thanks for the script, but it's too much of a hack for my taste... I'd rather wait for a working repacker (and accept the slow IO operations until then )
_________________
if only I could fill my heart with love... |
|
| Back to top |
|
|
Kaapeli
Tux's lil' helper
Joined: 27 Dec 2004
Posts: 110
Location: Oulu, Finland
|
| Posted: Sun May 01, 2005 9:11 am Post subject: |
|
|
| Tiger683 wrote: | A better bet would be to use
and
inbetween just rm -Rf ./* on the partition (or directory)
fragmentation of freespace drops to 0 then, well, disregarding reiser4 flaws that is....
|
Thanks for your comments.
Yes, of course. If you tar pack the whole content to another partition, empty it and then put it all back, that would most definitely be the most optimal solution. However, my goal was merely to emulate the repacker, to copy the files inside of the filesystem to allow it be written to the disk again in better optimized order. It seems to give rather good performance increase by doing it the way I did even though the partition I was operating with was 70% full.
_________________
Temperatures |
|
| Back to top |
|
|
thubble
Tux's lil' helper
Joined: 16 May 2003
Posts: 119
Location: Winnipeg, Canada
|
| Posted: Mon May 02, 2005 12:31 am Post subject: |
|
|
I used to manually enable the "broken" repacker on old Reiser4 snapshots. I ran it once in each direction, and didn't experience any problems, but it didn't provide any speedup either. Unfortunately on recent snapshots the repacker code has been removed completely instead of just disabled.  |
|
| Back to top |
|
|
Tiger683
Veteran
Joined: 08 Jan 2005
Posts: 1347
Location: Heffner's House
|
| Posted: Mon May 02, 2005 6:22 am Post subject: |
|
|
You dont have to tar it into another partition ;P
Given that you have ebough space on the current one
you still get the tar.bz2 in one fregment.
then just do
| Code: |
for i in *; do if $i != BLAH.tar.bz2 rm -Rf $i;
done;
|
Im not a bash h4x0r, but sth like that should do the trick.
Pack it together with the tar/untar option into a bash script and put into /bin; preceding with "cd /;"
in the script, name it r4repack or whatever and u have your thing;
ofcourse, it might also delete everything if theres even a typo in the check-for-tar-file-$i part
But, conceptually its the idea
T
_________________
Retired gentoo user |
|
| Back to top |
|
|
Kaapeli
Tux's lil' helper
Joined: 27 Dec 2004
Posts: 110
Location: Oulu, Finland
|
| Posted: Tue May 03, 2005 10:42 am Post subject: Some more benchmarks and testing... |
|
|
I've been doing some more experimenting and benchmarking with this thing today. I realized that there is a very simple alternte method for rewriting the files to the disk;
| Code: |
tar -c /directory/to/operate/with | tar -xv
|
This method works best with large fragmented files. It doesn't modify the content of the files, it doesn't modify file or directory attributes, but it does change link timestamps. Compared to the previous method, directory timestamps and inode numbers will remain the same. However, this method doesn't rewrite the directory structure. Therefore, if there is a fragmented directory with a lot of subdirectories, you may not gain as much improvement as you could with the cp -a method.
I tested this on my old home directory which contained many large files. Most of the files were already very well located on the disk, read performance was excellent among most of the files.
| Code: |
# mount oldroot/
#t ime tar -cf /dev/zero oldroot/home/kaapeli/
real 3m25.904s
user 0m0.618s
sys 0m36.722s
|
And the magic trick:
| Code: |
# tar -c oldroot/home/kaapeli/ | tar -cv
|
And another read test
| Code: |
# umount oldroot/ && mount oldroot/
# time tar -cf /dev/zero oldroot/home/kaapeli/
real 3m10.905s
user 0m0.603s
sys 0m37.772s
|
As you can see, there was only very little of improvement. However, while the read the files after the operation, the read speed was quite constantly within 30 - 40 MB/s range. Before the tar operation I could read many of the files over 50 MB/s while some other large files crawled as slow as 10 MB/s. Conclusion: It is no good to rewrite files which are already well located on the disk. The read performance may even degrade if the free space on the partition is fragmented. So, only rewrite files which are badly fragmented. That will give you the best performance boost and costs you least amout of time. On the other words, use your common sense
Second benchmark
This time I decided to optimize my old /usr/portage directory. Read test with tar indicated that the files distfiles directory were perfectly packed, so I simply moved the distfile directory outside of the portage directory while I did this test. As our previous test indicated, it is no good to try optimizing something that's already optimal
Read performance before the test:
| Code: |
# umount oldroot/ && mount oldroot/
# time tar -cf /dev/zero oldroot/usr/portage/root/tmp/
real 0m33.997s
user 0m0.808s
sys 0m5.457s
# umount oldroot/ && mount oldroot/
# time tar -cf /dev/zero oldroot/usr/portage/
real 0m35.418s
user 0m0.815s
sys 0m5.441s
|
Repacker emulation:
| Code: |
# tar -c oldroot/usr/portage/ | tar -xv
|
And the tead test after the operation:
| Code: |
# umount oldroot/ && mount oldroot/
# time tar -cf /dev/zero oldroot/usr/portage/
real 0m20.152s
user 0m0.738s
sys 0m5.078s
# umount oldroot/ && mount oldroot/
# time tar -cf /dev/zero oldroot/usr/portage/
real 0m20.327s
user 0m0.778s
sys 0m5.165s
|
40% drop on the read time.
However, this method doesn't rewrite the directories. I wanted to see whether rewriting the directories as well had any further impact on the performance. So, I ran the other script too to see if it could still make any difference.
| Code: |
# cd oldroot/usr/portage/
# for i in * ; do echo "$i" && cp -a "$i" "$i".back && rm -rf "$i" && mv "$i".back "$i" ; done
# cd ../../..
# umount oldroot/ && mount oldroot/
# time tar -cf /dev/zero oldroot/usr/portage/
real 0m16.151s
user 0m0.774s
sys 0m4.958s
# umount oldroot/ && mount oldroot/
# time tar -cf /dev/zero oldroot/usr/portage/
real 0m16.744s
user 0m0.756s
sys 0m5.057s
|
That is 18% improvement compared to the previous situation and 51% improvement compared to the original situation.
It seems that in some cases rewriting the directory structure can increase the performance more than just rewriting the files inside of the directories. This of course depends on how badly fragmented the directory strucuture is and how badly fragmented files there are.
I've used the tar method to rewrite my irclog files and it seems to make grep searches much faster. Logs and other slowly incrementing large files seem to get fragmented quite easily (i've witnessed this to happend on other filesystems (xfs at least) too). If you need to do searching on your logs, it makes sense to occassionally rewrite them to the disk to make them more sequential again.
Any comments are welcome.
_________________
Temperatures |
|
| Back to top |
|
|
Gentree
Watchman
Joined: 01 Jul 2003
Posts: 5350
Location: France, Old Europe
|
| Posted: Sat May 07, 2005 1:01 am Post subject: |
|
|
cp -a r4dir/* somewhere_else
umount ...
mkfs -t reiser4 ...
mount
cp -a somewhere_else/* r4dir
Judging by the drop in the noise comming from the drive it took a load off the mechanism.
_________________
Linux, because I'd rather own a free OS than steal one that's not worth paying for.
Gentoo because I'm a masochist
AthlonXP-M on A7N8X. Portage ~x86 |
|
| Back to top |
|
|
wishkah
Guru
Joined: 09 May 2003
Posts: 441
Location: de
|
| Posted: Fri May 13, 2005 4:18 pm Post subject: |
|
|
I heard rumors (no confirmation, just some mailing list entries) that they wanna charge your for the repacker (quote: "Hans needs money"). Any comment/confirmation/troll-killing?
_________________
if only I could fill my heart with love... |
|
| Back to top |
|
|
infirit
l33t
Joined: 11 Jan 2003
Posts: 778
Location: Hoofddorp / The Netherlands
|
| Posted: Sun May 22, 2005 1:38 pm Post subject: |
|
|
| wishkah wrote: | | I heard rumors (no confirmation, just some mailing list entries) that they wanna charge your for the repacker (quote: "Hans needs money"). Any comment/confirmation/troll-killing? |
There will be a really simple and basic repacker in reiser4 (hopefully 4.1). I'm not sure if it will be an online or an offline repacker 
edit: Just checked the mailing list, compression is for 4.1 not the repacker sigh
_________________
EASY TO INSTALL = Difficult to install, but instruction manual has pictures.
Join the adopt an unanswered post initiative today |
|
| Back to top |
|
|
SoTired
Apprentice
Joined: 19 May 2004
Posts: 174
|
| Posted: Mon May 23, 2005 3:23 am Post subject: |
|
|
| wishkah wrote: | | I heard rumors (no confirmation, just some mailing list entries) that they wanna charge your for the repacker (quote: "Hans needs money"). Any comment/confirmation/troll-killing? |
| Hans Reiser on the mailing list 05/06/05 01:06 according to thunderbird wrote: | | I think someone is going to pay us to write the online repacker in the very near future, though I can't say their name. |
Basically, Hans just wants someone to give some sponsoring money - since I've been on the list nothing has come up about charging end-users for the repacker. |
|
| Back to top |
|
|
mwirth
n00b
Joined: 26 Oct 2004
Posts: 28
|
| Posted: Fri May 27, 2005 11:26 pm Post subject: |
|
|
I have two reiser4 partitions that are about eight months old, /home and /, and both are down to about 6MB/s read transfer rate (when copying data to another hard disk!!). The disk should be capable of 40 to 50 MB/s. A vfat partition on the same disk achieves about 30MB/s transfer rate.
Even scp from my notebook (via 100Mbps ethernet) is faster than my reiser4 partitions
Which brings us to the conclusion that we really NEED a repacker. Otherwise, the claims of reiser4 being the fastest filesystem are just laughable...
I'm probably going to migrate my system to ext3 partitions unless a repacker (an offline version would do just fine) is released really soon. |
|
| Back to top |
|
|
mirko_3
l33t
Joined: 02 Nov 2003
Posts: 605
Location: Birreria
|
| Posted: Sat May 28, 2005 5:37 am Post subject: |
|
|
Have you tried this script?
_________________
Non fa male! Non fa male! |
|
| Back to top |
|
|
infirit
l33t
Joined: 11 Jan 2003
Posts: 778
Location: Hoofddorp / The Netherlands
|
| Posted: Sun May 29, 2005 12:55 am Post subject: |
|
|
Do not run this script in /bin, /lib or /sbin. It holds the commands and files that are needed by the script.
_________________
EASY TO INSTALL = Difficult to install, but instruction manual has pictures.
Join the adopt an unanswered post initiative today |
|
| Back to top |
|
|
pussi
l33t
Joined: 08 May 2004
Posts: 727
Location: Finland
|
| Posted: Sun May 29, 2005 8:14 am Post subject: |
|
|
| infirit wrote: | | Do not run this script in /bin, /lib or /sbin. It holds the commands and files that are needed by the script. |
I think you are supposed to run this from livecd or some other external environment. |
|
| Back to top |
|
|
M@rijn
Tux's lil' helper
Joined: 28 Jan 2004
Posts: 145
Location: Zierikzee (The Netherlands)
|
| Posted: Sun May 29, 2005 10:34 am Post subject: |
|
|
Doesn't it have the same effect when i start the Boot CD tar my / partition scp it to my server, rebuild reiser4 partitions and put the tar back? Or will i have the same (slow) effect after it?
_________________
Gentoo is just an Aston Martin, "Power, beauty and soul" |
|
| Back to top |
|
|
mirko_3
l33t
Joined: 02 Nov 2003
Posts: 605
Location: Birreria
|
| Posted: Sun May 29, 2005 11:05 am Post subject: |
|
|
Yeah, that's what the script wants to achieve, in a quicker way and skipping the scp part...
_________________
Non fa male! Non fa male! |
|
| Back to top |
|
|
Lore
Apprentice
Joined: 16 Feb 2004
Posts: 152
Location: Karlsruhe
|
| Posted: Thu Jun 16, 2005 11:48 pm Post subject: |
|
|
Long, long time ago, there where ancient filesystems, which had to be defragmentated every once in a while. Then the wise men invented better filesystems. The masses praised the wise men because life went much easier.
Nowadays, a new hero arised, call the reiser4. This filesystem is much, much better than all other filesystem. The only flaw is, that it has to be repacked every once in a while.
And the wheel of time goes on and on. |
|
| Back to top |
|
|
mirko_3
l33t
Joined: 02 Nov 2003
Posts: 605
Location: Birreria
|
| Posted: Fri Jun 17, 2005 9:27 am Post subject: |
|
|
Is reiser4 vulnerable to balefire though? I suppose it is... 
_________________
Non fa male! Non fa male! |
|
| Back to top |
|
|
Kaapeli
Tux's lil' helper
Joined: 27 Dec 2004
Posts: 110
Location: Oulu, Finland
|
| Posted: Sat Jun 18, 2005 2:53 pm Post subject: |
|
|
| Lore wrote: | Long, long time ago, there where ancient filesystems, which had to be defragmentated every once in a while. Then the wise men invented better filesystems. The masses praised the wise men because life went much easier.
Nowadays, a new hero arised, call the reiser4. This filesystem is much, much better than all other filesystem. The only flaw is, that it has to be repacked every once in a while.
And the wheel of time goes on and on. |
Can you mention a filesystem that does not require defragmenting/repacking once in a while? As far as I know, such a filesystem does not exist. If you continuously shuffle the files around on your disk, all filesystems will inevitably lose their integrity without active repacking, reorganizing, defragmenting or how ever you wish to call it.
_________________
Temperatures |
|
| Back to top |
|
|
adaptr
Watchman
Joined: 06 Oct 2002
Posts: 6730
Location: Rotterdam, Netherlands
|
| Posted: Sat Jun 18, 2005 3:14 pm Post subject: |
|
|
Not an existing one, no.
But it is certainly possible.
Think about why fragmentation occurs: it depends on the assigment of free blocks both when creating a file on a fresh part of the filesystems' bitmap, and by a much greater amount on the assignment of blocks from reclaimed parts of a (polluted) bitmap - one with many small gaps in it.
The last one is what causes most of the unpredictable fragmentation, since a smart FS can take measures to ensure that really new files do not get fragmented if sufficient space is available.
But say we extend this "smartness" to maintaining (or rebuilding) an on-disk meta-bitmap of consecutive free blocks, sorted by size and accessibility (nearness).
Put that through the same B-tree algorithms Reiser uses for the inodes and you should be able to optimise placement of any new files - wheter on new blocks or re-used parts of the disk.
A muilti-tier "bitmap of bitmaps" would probably work best, a la CPU caching.
Of course, it incurs overhead, but not as much as you'd think, since one would obviously code for the trivial case - the most common re-assignments of free space - which occur most often.
Any of the +-stdev occurences outside this mean would only need to be performed occasionally - and one could even put those processes on a backburner: less "live" than the normal allocator, but not completely offline like a repacker.
Reiser5, hmm ?
_________________
>>> emerge (3 of 7) mcse/70-293 to /
Essential tools: gentoolkit eix profuse screen |
|
| Back to top |
|
|
Lore
Apprentice
Joined: 16 Feb 2004
Posts: 152
Location: Karlsruhe
|
| Posted: Sat Jun 18, 2005 8:56 pm Post subject: |
|
|
@Kaapeli
[As a preface, I'm a user of reiser4 and I like.]
I'm thinking of my Windows 95 days. At that time you have to defragment your FAT filesystem to avoid a siginifcant amount of efficiency. Reiser3, ext3 and co. are able to be efficient over an unpredictable time. So it's quite scaring to me running a maintenance tool to keep reiser4 efficient. |
|
| Back to top |
|
|
asimon
l33t
Joined: 27 Jun 2002
Posts: 979
Location: Germany, Old Europe
|
| Posted: Wed Jun 22, 2005 8:42 am Post subject: |
|
|
| wishkah wrote: | | I heard rumors (no confirmation, just some mailing list entries) that they wanna charge your for the repacker (quote: "Hans needs money"). Any comment/confirmation/troll-killing? |
Hans Reiser - Re: Reiser4 repackers. |
|
| Back to top |
|
|
|
Unsupported Software
