Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
ReiserFS tuning thread, the mother of all "ricer" threads ;)
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4, 5  Next  
Reply to topic    Gentoo Forums Forum Index Unsupported Software
View previous topic :: View next topic  
Author Message
energyman76b
Advocate
Advocate


Joined: 26 Mar 2003
Posts: 2045
Location: Germany

PostPosted: Sat Oct 25, 2008 11:27 am    Post subject: Reply with quote

also, the partition you copy from should be the same fs as the partition you copy to.
_________________
Study finds stunning lack of racial, gender, and economic diversity among middle-class white males

I identify as a dirty penismensch.
Back to top
View user's profile Send private message
Yamakuzure
Advocate
Advocate


Joined: 21 Jun 2006
Posts: 2273
Location: Bardowick, Germany

PostPosted: Thu Oct 30, 2008 2:37 pm    Post subject: Reply with quote

Hi there!

I am just experimenting a bit with reiser4, as I have two unused partitions to play around with.
After reading this thread I formated them with
Code:
# mkfs.reiser4 -o create=ccreg40,compress=gzip1,compressMode=force,cluster=8K,fibration=lexic_fibre,formatting=smart -L test1 /dev/sda5
# mkfs.reiser4 -o create=ccreg40,cluster=8K,fibration=lexic_fibre,formatting=smart -L test2 /dev/sda10
I mounted the first one with "noatime,nodiratime,flush.scan_maxnodes=12000" to /home/r4test1 and the second one with "noatime,nodiratime" to /home/r4test2.
I copied /usr/portage (with -rp option) to both folders. I wanted to test how much space and speed is gained, so I used time on du:
Code:
# time du -hs /usr/portage;time du -hs /home/r4test1;time du -hs /home/r4test2
484M    /usr/portage
real    0m14.303s
user    0m0.123s
sys     0m0.538s

903M    /home/r4test1
real    0m11.553s
user    0m0.203s
sys     0m2.188s

901M    /home/r4test2
real    0m14.132s
user    0m0.184s
sys     0m2.197s
Now look at this, the gzip-compressed one takes more space but is faster than the lzo compressed one, but both eat up nearly twice the space than a reiser3 partition?

What did I do wrong here?

--- edit ---
Another test, I unmounted both partitions, and reformatted with:
Code:
# mkfs.reiser4 -o compress=gzip1 -L test1 /dev/sda5
# mkfs.reiser4 -L test1 /dev/sda10
Copying:
Code:
# time cp -rp /usr/portage /home/r4test1/;time cp -rp /usr/portage /home/r4test2/

real    4m49.021s
user    0m0.987s
sys     0m12.702s

real    4m48.510s
user    0m0.937s
sys     0m12.209s
du:
Code:
# time du -hs /home/r4test1/portage;time du -hs /home/r4test2/portage
201M    /home/r4test1/portage
real    0m18.566s
user    0m0.196s
sys     0m2.525s

201M    /home/r4test2/portage
real    0m18.858s
user    0m0.191s
sys     0m2.661s
So it seems using custom options makes reiser4 somewhat faster (at least "du" is faster) but eats up alot of space? Well 903M->201M is quite a difference, huh?

--------- Addition -------------
Code:
# time rm -rf /home/r4test1/*;time rm -rf /home/r4test2/*

real    0m27.022s
user    0m0.239s
sys     0m9.391s

real    0m23.799s
user    0m0.220s
sys     0m8.751s
I guess using gzip1 is a bad idea for my machine, right? ;)
_________________
Important German:
  1. "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
  2. "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
Back to top
View user's profile Send private message
kernelOfTruth
Watchman
Watchman


Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)

PostPosted: Thu Oct 30, 2008 2:48 pm    Post subject: Reply with quote

Quote:
Now look at this, the gzip-compressed one takes more space but is faster than the lzo compressed one, but both eat up nearly twice the space than a reiser3 partition?

What did I do wrong here?


for me a partition with gzip-compression (in an ideal scenario) only needs 1/2 or even 1/3 of the space of an reiser3 partition

your results are flawed:

you unmounted the partition before doing a du on it ? another way would be to check whether VFS is dirty:

cat /proc/meminfo

Quote:
Dirty: 202244 kB
Writeback: 0 kB


e.g. says that there's still files to be written / the results won't be accurate

energyman, any comments ?
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa

Hardcore Gentoo Linux user since 2004 :D
Back to top
View user's profile Send private message
Yamakuzure
Advocate
Advocate


Joined: 21 Jun 2006
Posts: 2273
Location: Bardowick, Germany

PostPosted: Thu Oct 30, 2008 3:03 pm    Post subject: Reply with quote

could be... or "du" can't handle partitions with reiser4 if create=ccreg40 is used:
Code:
# mkfs.reiser4 -o create=ccreg40,compress=gzip1 -L test1 /dev/sda5
# mkfs.reiser4 -o create=ccreg40 -L test1 /dev/sda10
Code:
# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda5             3,6G  244K  3,6G   1% /home/r4test1
/dev/sda10            7,0G  368K  7,0G   1% /home/r4test2
Code:
# time cp -rp /usr/portage /home/r4test1/;time cp -rp /usr/portage /home/r4test2/

real    4m43.070s
user    0m0.913s
sys     0m10.896s

real    4m39.528s
user    0m0.915s
sys     0m11.229s
Code:
# time du -hs /home/r4test1/portage;time du -hs /home/r4test2/portage
6,7G    /home/r4test1/portage
real    0m11.912s
user    0m0.178s
sys     0m2.160s

6,7G    /home/r4test2/portage
real    0m13.677s
user    0m0.195s
sys     0m2.414s
Code:
# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda5             3,6G  102M  3,5G   3% /home/r4test1
/dev/sda10            7,0G  130M  6,8G   2% /home/r4test2
Is that weird?

btw.:
Code:
# cat /proc/meminfo
Dirty:              24 kB
Writeback:           0 kB


Edit: Yep, I thing "du" is getting the whole thing wrong.
Mental Note to self: Forget about "du" and use "dh" where possible!
Code:
# umount /home/r4test2
# mkfs.reiser4 -o create=ccreg40,compress=gzip1,compressMode=force,cluster=8K,fibration=lexic_fibre,formatting=smart -L test2 /dev/sda10
mkfs.reiser4 1.0.6
Copyright (C) 2001-2005 by Hans Reiser, licensing governed by reiser4progs/COPYING.

Overriding the plugin profile by
"create=ccreg40,compress=gzip1,compressMode=force,cluster=8K,fibration=lexic_fibre,formatting=smart".
Block size 4096 will be used.
Linux 2.6.25-gentoo-r7 is detected.
Uuid ffad1e88-56dd-49be-ae5e-30b497cca0d4 will be used.
Reiser4 is going to be created on /dev/sda10.
(Yes/No): Yes
Creating reiser4 on /dev/sda10 ... done
# mount /home/r4test2
# time cp -rp /usr/portage /home/r4test2/

real    4m42.231s
user    0m0.903s
sys     0m10.910s
# umount /home/r4test2;mount /home/r4test2
# umount /home/r4test1;mount /home/r4test1
# time du -hs /home/r4test1/portage;time du -hs /home/r4test2/portage

6,7G    /home/r4test1/portage
real    0m10.125s
user    0m0.211s
sys     0m2.135s

903M    /home/r4test2/portage
real    0m11.564s
user    0m0.182s
sys     0m2.524s
# LC_ALL="C" df -h /dev/sda5 /dev/sda10
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda5             3.6G  102M  3.5G   3% /home/r4test1
/dev/sda10            7.0G  103M  6.9G   2% /home/r4test2

_________________
Important German:
  1. "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
  2. "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
Back to top
View user's profile Send private message
energyman76b
Advocate
Advocate


Joined: 26 Mar 2003
Posts: 2045
Location: Germany

PostPosted: Thu Oct 30, 2008 4:40 pm    Post subject: Reply with quote

kernelOfTruth wrote:
Quote:
Now look at this, the gzip-compressed one takes more space but is faster than the lzo compressed one, but both eat up nearly twice the space than a reiser3 partition?

What did I do wrong here?


for me a partition with gzip-compression (in an ideal scenario) only needs 1/2 or even 1/3 of the space of an reiser3 partition

your results are flawed:

you unmounted the partition before doing a du on it ? another way would be to check whether VFS is dirty:

cat /proc/meminfo

Quote:
Dirty: 202244 kB
Writeback: 0 kB


e.g. says that there's still files to be written / the results won't be accurate

energyman, any comments ?


yes, with all that options used I am surprised that his system survived at all ;)

Don't force compression. On already compressed data it increases the size used a lot. Also, don't belief du or even with dh. With compression both are constantly reporting wrong sizes.
du is always wrong, df can be correct.
Just copy a multi gigabyte directory containing a lot of compressible and incompressible stuff to a compression r4 partition and watch with dh.

You will see something like that:
2 used 14 free
3 used 13 free
4 used 12 free
2,5 used, 13,5 free
3 used 13 free
....

if you want 'real' numbers you need to unmount (and maybe fsck - that way the bogus size information will be corrected (looks scary like hell)). Or you live with the fact that both df and du are a bit off.

for example. My /var partition.
df says:
/dev/md2 18G 12G 6,2G 66% /var
du says:
37G /var

df -h is pretty close to reality - because I just booted.
_________________
Study finds stunning lack of racial, gender, and economic diversity among middle-class white males

I identify as a dirty penismensch.
Back to top
View user's profile Send private message
DigitalCorpus
Apprentice
Apprentice


Joined: 30 Jul 2007
Posts: 245

PostPosted: Fri Oct 31, 2008 6:28 am    Post subject: Reply with quote

I've noticed that the poor-man's fix for fsck-ing a reiser4 partition to get correct sizes from at least df is to use sync. I took my server down last sunday and upped it's RAM from 2GB to 8GB. As such I'm not using my swap partition even a little right now. Since it is 4 GiB of disk space about 10 GiB in on a 640GB disk I think it would still yield some mentionable results. I'm off on Sunday so I may just have some time for benchmarking.

I'll be looking at copying from /dev/shm (native RAM disk right?) and to it to get read/write speeds. With any compression in Reiser4, I think that I/Os are still limited by CPU and not the disk mechanism. Guess we can find a little answer to that. I've stably run my Q6700 at a stable 3.5GHz so doing a bit of overclocking might help in the benchmarks. Reads, writes, locate, space efficiency. I can do a portage tree for small files as well as a 1.1GB (compressed) Ccache and the distfiles directory for compressed files on a compressed filesystem. What other type of files should I be testing? I have uncompressed TIFFs readily at hand?

fdisk readout
Code:
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1        1326    10651063+  83  Linux
/dev/sda2   *        1327        1329       24097+  83  Linux
/dev/sda3            1330        1852     4200997+  82  Linux swap / Solaris
/dev/sda4            1853       77826   610261155    f  W95 Ext'd (LBA)
/dev/sda5            1853        2564     5719077   83  Linux
/dev/sda6            2565        8511    47769246   83  Linux
/dev/sda7            8512       73848   524819421   83  Linux
/dev/sda8           73849       77825    31945221   83  Linux

_________________
Atlas (HDTV PVR, HTTP & Media server)
http://atlas.selfip.net/Info/
Back to top
View user's profile Send private message
kernelOfTruth
Watchman
Watchman


Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)

PostPosted: Sat Dec 27, 2008 11:28 am    Post subject: Reply with quote

ok guys,

here are the settings for those who like to use reiserfs and/or reiser4 with cfq i/o scheduler:

Quote:
for i in /sys/block/sd*; do
/bin/echo "cfq" > $i/queue/scheduler
/bin/echo "0" > $i/queue/iosched/slice_idle
/bin/echo "64" > $i/queue/iosched/quantum
done


and ideally (if you're having drives with ncq)
Code:
for i in /sys/block/sd*; do
         /bin/echo "1024" >  $i/queue/nr_requests
         /bin/echo "2" >  $i/device/queue_depth
done



I get the best results with them so far ...

before you begin using cfq in favor of other i/o scheduler make sure that you get at least the same burst / maximal throughput like with the other schedulers:

Code:
hdparm -tT /dev/foo


e.g. if you get

Quote:
hdparm -tT /dev/sda

/dev/sda:
Timing cached reads: 5428 MB in 2.00 seconds = 2719.87 MB/sec
Timing buffered disk reads: 184 MB in 3.02 seconds = 60.95 MB/sec


and it goes down to

Quote:
hdparm -tT /dev/sda

/dev/sda:
...
Timing buffered disk reads: 184 MB in 3.02 seconds = 33.26 MB/sec


you're affected by a nasty BUG on cfq and should join in the discussion on lkml.org and report your results to Jens Axboe
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa

Hardcore Gentoo Linux user since 2004 :D


Last edited by kernelOfTruth on Sat Dec 27, 2008 11:00 pm; edited 1 time in total
Back to top
View user's profile Send private message
DigitalCorpus
Apprentice
Apprentice


Joined: 30 Jul 2007
Posts: 245

PostPosted: Sat Dec 27, 2008 11:50 am    Post subject: Reply with quote

kernelOfTruth wrote:
ok guys,

here are the settings for those who like to use reiserfs and/or reiser4 with cfq i/o scheduler:

Quote:
for i in /sys/block/sd*; do
/bin/echo "cfq" > $i/queue/scheduler
/bin/echo "0" > $i/queue/iosched/slice_idle
/bin/echo "64" > $i/queue/iosched/quantum
done


I get the best results with them so far ...

What do these modifications do, besides speed things up?

Quote:
you're affected by a nasty BUG on cfq and should join in the discussion on lkml.org and report your results to Jens Axboe

Thank you for the heads up. This bug only affects both of my 2 HDDs. That is kind of strange though because it affects different partitions, not every one of them. I'm going to test 2.6.28 to see if it is still affecting me.

Edit: This bug/patch is the one I assume you are talking about:
http://lwn.net/Articles/114734/
_________________
Atlas (HDTV PVR, HTTP & Media server)
http://atlas.selfip.net/Info/
Back to top
View user's profile Send private message
zyko
l33t
l33t


Joined: 01 Jun 2008
Posts: 620
Location: Munich, Germany

PostPosted: Sat Dec 27, 2008 9:41 pm    Post subject: Reply with quote

Could you elaborate a little on the cluster=n option? What usage scenarios would benefit from a smaller (than the default 64K) cluster size?
Back to top
View user's profile Send private message
kernelOfTruth
Watchman
Watchman


Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)

PostPosted: Sat Dec 27, 2008 10:49 pm    Post subject: Reply with quote

zyko wrote:
Could you elaborate a little on the cluster=n option? What usage scenarios would benefit from a smaller (than the default 64K) cluster size?


DigitalCorpus wrote:

Quote:
cluster=8K: It is important to remember that the 'K' is capital otherwise this plugin parameter is rejected. We cannot use anything other than 4K blocks when we use Reiser4. This is a workaround of sorts. From what I've seen so far this parameter tells Reiser4 to look at data in <8K> chunks/clusters. Why does this matter? Two things. First, we are still waiting for Reiser4 to have kernel support for i_bytes and i_blocks. When a file is written to disk under a ccreg40 formated reiser4 partition, its real compressed size is not recorded, but instead this value is recorded in its place. This means that if you know you are working with a bunch of small files, set this value to 4K or 8K to help Reiser4 flush it's cache so frequently as it's perceived that it is not filling up disk space as quickly as setting this to 16K, 32K or the default of 64K. The second reason is efficiency in compression. If you have mid to large size files stored on the partition, Reiser4 will compress in <8K> parts. So if you know you are storing larger files, use 32K or 64K for increased compression. This last part is assumed as I have not actually tested it, but it stands to reason given it's behavior when recording [inaccurate] file sizes. I'd suggest a benchmark such as copying 200-500 MiB of uncompressed TIFF files to a Reiser4 partition and test time and final size after fsck-ing the partition to test this theory


from what I saw this proved to be true ...

if you're really interested in it you could ask Edward about it - I'm currently fine with the behavior and performance of my reiser4-partitions so I need no further tweaks right now ...

status quo is pretty stable and fast for and I need work to do so I'll try out newer exotic things later ... :P
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa

Hardcore Gentoo Linux user since 2004 :D


Last edited by kernelOfTruth on Sat Dec 27, 2008 11:04 pm; edited 1 time in total
Back to top
View user's profile Send private message
kernelOfTruth
Watchman
Watchman


Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)

PostPosted: Sat Dec 27, 2008 10:59 pm    Post subject: Reply with quote

DigitalCorpus wrote:
kernelOfTruth wrote:
ok guys,

here are the settings for those who like to use reiserfs and/or reiser4 with cfq i/o scheduler:

Quote:
for i in /sys/block/sd*; do
/bin/echo "cfq" > $i/queue/scheduler
/bin/echo "0" > $i/queue/iosched/slice_idle
/bin/echo "64" > $i/queue/iosched/quantum
done


I get the best results with them so far ...

What do these modifications do, besides speed things up?

Quote:
you're affected by a nasty BUG on cfq and should join in the discussion on lkml.org and report your results to Jens Axboe

Thank you for the heads up. This bug only affects both of my 2 HDDs. That is kind of strange though because it affects different partitions, not every one of them. I'm going to test 2.6.28 to see if it is still affecting me.

Edit: This bug/patch is the one I assume you are talking about:
http://lwn.net/Articles/114734/


they're speeding things up - exactly, and they help to partly "fix" the mentioned bug to some extent:

1) by setting slice_idle to "0" (cfq doesn't wait which in turn leads to slightly higher fragmentation on the one hand from what I read and on the other faster processing because it's not waiting for data to collect and re-ordering)
2) raising quantum to "64" which is something like cfq's dispatch queue to let it do a better job in a shorter time in writing stuff to disks)

don't forget to add:
Code:
for i in /sys/block/sd*; do
         /bin/echo "1024" >  $i/queue/nr_requests
         /bin/echo "2" >  $i/device/queue_depth
done

this almost completely moves the file queuing from the harddrive to the i/o scheduler (which is supposed to do the better job than the bad ncq of most of the drives
from what I read - and my experience)

the article you mentioned refers to that BUG in fact it seems to exist pretty long already (from what I saw 2003 or 2004 ?! bear with me if that's 2 years too early ;) )
http://www.google.com/search?hl=en&q=lkml+cfq+anticipatory+regression&btnG=Google-Suche&meta=

the topic is called
Quote:
performance "regression" in cfq compared to anticipatory, deadline and noop

it's not a regression but BUG like Jens wrote, and compared to the article you mentioned it's not only affecting write but also read performance - at least by 40%:

Quote:
I've been experiencing this for a while also; an almost 50% regression
is seen for single-process reads (ie sync) if slice_idle is 1ms or
more (eg default of 8) [1], which seems phenomenal.

Jens, is this the expected price to pay for optimal busy-spindle
scheduling, a design issue, bug or am I missing something totally?

Thanks,
Daniel

--- [1]
# cat /sys/block/sda/queue/iosched/slice_idle
8
# echo 1 >/proc/sys/vm/drop_caches
# dd if=/dev/sda of=/dev/null bs=64k count=5000
5000+0 records in
5000+0 records out
327680000 bytes (328 MB) copied, 4.92922 s, 66.5 MB/s
# echo 0 >/sys/block/sda/queue/iosched/slice_idle
# echo 1 >/proc/sys/vm/drop_caches
# dd if=/dev/sda of=/dev/null bs=64k count=5000
5000+0 records in
5000+0 records out
327680000 bytes (328 MB) copied, 2.74098 s, 120 MB/s
# hdparm -Tt /dev/sda

/dev/sda:
Timing cached reads: 15464 MB in 2.00 seconds = 7741.05 MB/sec
Timing buffered disk reads: 342 MB in 3.01 seconds = 113.70 MB/sec

[120MB/s is known platter-rate for this disc, so expected]
--
Daniel J Blueman

http://lkml.org/lkml/2008/5/11/48
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa

Hardcore Gentoo Linux user since 2004 :D


Last edited by kernelOfTruth on Sat Dec 27, 2008 11:11 pm; edited 1 time in total
Back to top
View user's profile Send private message
kernelOfTruth
Watchman
Watchman


Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)

PostPosted: Sat Dec 27, 2008 11:06 pm    Post subject: Reply with quote

energyman76b wrote:
kernelOfTruth wrote:
Quote:
Now look at this, the gzip-compressed one takes more space but is faster than the lzo compressed one, but both eat up nearly twice the space than a reiser3 partition?

What did I do wrong here?


for me a partition with gzip-compression (in an ideal scenario) only needs 1/2 or even 1/3 of the space of an reiser3 partition

your results are flawed:

you unmounted the partition before doing a du on it ? another way would be to check whether VFS is dirty:

cat /proc/meminfo

Quote:
Dirty: 202244 kB
Writeback: 0 kB


e.g. says that there's still files to be written / the results won't be accurate

energyman, any comments ?


yes, with all that options used I am surprised that his system survived at all ;)

Don't force compression. On already compressed data it increases the size used a lot. Also, don't belief du or even with dh. With compression both are constantly reporting wrong sizes.
du is always wrong, df can be correct.
Just copy a multi gigabyte directory containing a lot of compressible and incompressible stuff to a compression r4 partition and watch with dh.


...


in theory yes - compressing compressed files should be omitted

in reality - however

reiser4 + lzo astonishingly is doing a really great job all of my data's still intact :P (and I at least had the same amount of options during creation enabled like he did)

by forcing compression I'm saving at least 2 GB of data on my system-partition and apps seem to launch fast enough (no adverse effects compared to non-forced compression despite the won
harddisk-space which I need on my laptop harddrive)


forced compression should be omitted on partitions where you often work with compressed files (e.g. creating system-backups from ebuilds -> quickpkg ...)
package-compression that way takes considerably longer and also flushing the cache seems to take considerably longer :idea:
and those tbz2-packages take up more space (like you wrote) :roll:
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa

Hardcore Gentoo Linux user since 2004 :D
Back to top
View user's profile Send private message
tel
Tux's lil' helper
Tux's lil' helper


Joined: 15 Aug 2006
Posts: 112

PostPosted: Wed Jan 07, 2009 5:42 pm    Post subject: Another Reiser4 question Reply with quote

Just playing around with filesystems, and I'm toying with the idea of putting Reiser4 on my portage tree partition, just to see how it functions.

I have a very old 800 Mhz Pentium III - do you think this system is too weak to make it worthwhile to use Reiser4? I understand it's fairly CPU-intensive.

Thanks.
Back to top
View user's profile Send private message
nixnut
Bodhisattva
Bodhisattva


Joined: 09 Apr 2004
Posts: 10974
Location: the dutch mountains

PostPosted: Wed Jan 07, 2009 5:54 pm    Post subject: Reply with quote

merged above post here
_________________
Please add [solved] to the initial post's subject line if you feel your problem is resolved. Help answer the unanswered

talk is cheap. supply exceeds demand
Back to top
View user's profile Send private message
kernelOfTruth
Watchman
Watchman


Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)

PostPosted: Wed Jan 07, 2009 8:11 pm    Post subject: Re: Another Reiser4 question Reply with quote

tel wrote:
Just playing around with filesystems, and I'm toying with the idea of putting Reiser4 on my portage tree partition, just to see how it functions.

I have a very old 800 Mhz Pentium III - do you think this system is too weak to make it worthwhile to use Reiser4? I understand it's fairly CPU-intensive.

Thanks.


afaik Simba7 has it running on Pentium III 600 MHz (multiprocessor ?),

for you guys having to run it on "not so strong" boxes, try the following:

mount it with

Quote:
dont_load_bitmap
Don't load all bitmap blocks at mount time, it is useful for
machines with tiny RAM and large disks.

_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa

Hardcore Gentoo Linux user since 2004 :D
Back to top
View user's profile Send private message
energyman76b
Advocate
Advocate


Joined: 26 Mar 2003
Posts: 2045
Location: Germany

PostPosted: Wed Jan 07, 2009 9:48 pm    Post subject: Reply with quote

kernelOfTruth wrote:
energyman76b wrote:
kernelOfTruth wrote:
Quote:
Now look at this, the gzip-compressed one takes more space but is faster than the lzo compressed one, but both eat up nearly twice the space than a reiser3 partition?

What did I do wrong here?


for me a partition with gzip-compression (in an ideal scenario) only needs 1/2 or even 1/3 of the space of an reiser3 partition

your results are flawed:

you unmounted the partition before doing a du on it ? another way would be to check whether VFS is dirty:

cat /proc/meminfo

Quote:
Dirty: 202244 kB
Writeback: 0 kB


e.g. says that there's still files to be written / the results won't be accurate

energyman, any comments ?


yes, with all that options used I am surprised that his system survived at all ;)

Don't force compression. On already compressed data it increases the size used a lot. Also, don't belief du or even with dh. With compression both are constantly reporting wrong sizes.
du is always wrong, df can be correct.
Just copy a multi gigabyte directory containing a lot of compressible and incompressible stuff to a compression r4 partition and watch with dh.


...


in theory yes - compressing compressed files should be omitted

in reality - however


in reality I measured it several times (and I own two dlt drives with built in hardware compression). And trying to compress already compressed files, like movies, mp3, jpg, increases the size A LOT. Between 10 and 100% percent.
_________________
Study finds stunning lack of racial, gender, and economic diversity among middle-class white males

I identify as a dirty penismensch.
Back to top
View user's profile Send private message
DigitalCorpus
Apprentice
Apprentice


Joined: 30 Jul 2007
Posts: 245

PostPosted: Fri Jan 09, 2009 7:55 am    Post subject: Reply with quote

there is another option you can use that I'm finding still provides good compression and performance. I still haven't been able to get working on proper benchmarks to help with this at all unfortunately.

Instead of using
Code:
compressMode=force
I have been using
Code:
compressMode=ultim

Instead of trying to compress every file, even mp3's, mpeg 1, 2, or 4 movies, gzipped or bzip2 files, it'll test to see if the file is compressible. If it is, reiser4 will remember that for the entire time the file exists on the system. If it isn't, then reiser4 will not try and compress the file for the entire life on the system.

The middle road between these two is
Code:
compressMode=conv
which is default.


Right now I'm experimenting with my portage partition and seeing how ultim works out. My portage tree rose from 103MiB to 109MiB, but I don't noticed any size increase other than that. Compilation is taking about 15-20% less time, maybe more or less, because it isn't passing the distfiles through a decompression algorithm first. This is an anecdotal number based on shorter compilation time of
Code:
emerge -e @system @world
with a greater number of packages than what I've had in the past. I used to compile ~250-275 packags in 107 minutes, now I have 414 in ~88 minutes both with -j4 and --jobs 4.
_________________
Atlas (HDTV PVR, HTTP & Media server)
http://atlas.selfip.net/Info/
Back to top
View user's profile Send private message
DigitalCorpus
Apprentice
Apprentice


Joined: 30 Jul 2007
Posts: 245

PostPosted: Mon Feb 09, 2009 10:47 am    Post subject: Maximizing performance and adding some safety Reply with quote

It isn't much fun to tweak a live system. I mean I do have a 4 GB partition sitting around, but I'd like to have just a little bit more control and avoid any more 'fatal' crashes. I've included some extra detail for those who don't know where to find certain pieces of information.

So far you can monitor how much data Reiser4 has not commited to disk by executing
Code:
cat /proc/meminfo | grep Dirty
but this goes for just about every FS. Reiser4 though prefers to make a cache in RAM first, and sort things out when it flushes everything to disk. This is a problem if you have kernel oops or seg fault or power loss when it hasn't completed flushing everything to disk. I've already had my shares of problems with this.

Looking at /usr/src/linux/Documentation/filesystems/reiser4.txt for the available mounting options for Reser4 I see two opitons that catch my interest: tmgr.atom_max_size and tmgr.atom_max_age.

Naturally I started toying with tmgr.atom_max_size for a bit since I figured it would limit the amount of data that would otherwise corrupt upon a crash. I found that changing this value drastically changes the performance of Reiser4, but to a point. The input is a simple decimal number, despite the fact that when you execute mount the value is in hex. I honestly cannot tell you if the block size is the standard 4KB or if it is the cluster size specified when creating the filesystem. What I have seen though is that there seems to be a threshold limit coded into Reiser4 to where it'll start flushing to the disk. I found this out from watching the "Dirty" count in /proc/meminfo when I set this to really high values, such as 51200. I did manage to get my highest throughput of about 53MB/sec with the limit so high. By comparingr stock mounting options and custom mounts of Reiser4, I believe this threshold is about 384MB. So despite having this really high, it'll stark syncing to disk once it gets to that point. This point could be modified by flush.scan_maxnodes, but I'm a bit too burnt to test it. If I set this value at 512, I would get no more than about 6 MB of data that was waiting to be flushed to disk while watching /proc/meminfo at a 0.5 sec resolution. My throughput suffered though with the average at about 23MB/sec. Dropping the value to 256 gave me about 12MB/sec. I saw marginal improvements over 2048 (does not have to be a power of 2) for my system.

Well, I got decent results for performance with large files (used a 1.3GB bzip2 tar file) when I set tmgr.atom_max_size way high, like 51200. Only problem was that after the copying was done, not everything was flushed to disk. So to test a bit more, I removed tmgr.atom_max_size from my mounting options and put in tmgr.atom_max_age. I wasn't sure of the units as the documentation states 600 which could be 6, 60, or 600 seconds given that there are no units. Simple test revealed that this is value is in seconds. I didn't think it was practical to try values between 1 and 0, so this was a quick one to test. After trying a few different values for tmgr.atom_max_age that were between 60 and 0, I'm set to stay at 1. Reason being is that when I set this to 0, the remaining dirty bytes were flushed to disk after 10 minutes (600 seconds). Also I noted that flushing would automatically commence, but would halt at around ~384MB until tmgr.atom_max_age was reached. It would then just flush the remaining data to disk.

From all of this I learned that if you have a system without much RAM and would like it to be used for things other than cache data to your disk, let Reiser4 decide what to set tmgr.atom_max_size too (Default is nr_free_pagecache_pages() / 2 at mount time according to the aforementioned doc). Also, if someone has slower disks to test this on to determine if it is a multiple of the 4KB block size or if it is a multiple of the block size set upon creation, it could help out quite a bit. You can set this as low as you wish too in order to make sure you don't have too much data cached by Reiser4 in RAM, but I would imagine that other than directly affecting performance when set too low, you would negatively affect the efficiency of data layout, fibration, and fragmentation of the data being written.

My HDD's have been able to top out at 120MB/sec write speeds according to hdparm. My maximum write speed with Reiser4 with my current formatting options is about 53MB/sec. If I take a bit of time out to tweak my tmgr.atom_max_size to the smallest possible without lowering that thorughput and set tmgr.atom_max_age to 1, then I won't be over committing RAM to Reiser4's caching and making sure that, as long as I don't have a crash in the middle of a read/write operation, I'm pretty sure I'll be hard pressed to loosing any more data. Keep in mind, your milage will varry. I would pause a second to add that I'd actually suggest doubling the value of the lowest tmgr.atom_max_size you can achieve so that way you'd get less fragmentation and better organization of files with the fibration you're using while still feeling comfortable with RAM usage.
_________________
Atlas (HDTV PVR, HTTP & Media server)
http://atlas.selfip.net/Info/
Back to top
View user's profile Send private message
DigitalCorpus
Apprentice
Apprentice


Joined: 30 Jul 2007
Posts: 245

PostPosted: Mon Feb 09, 2009 11:27 am    Post subject: Reply with quote

Well I just realized that adding sync to the mount options does effectively the same thing I spent the past few hours looking at trying to achieve :oops: :oops: . At least I learned a few things in the process :roll: :wink: .
_________________
Atlas (HDTV PVR, HTTP & Media server)
http://atlas.selfip.net/Info/
Back to top
View user's profile Send private message
kernelOfTruth
Watchman
Watchman


Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)

PostPosted: Fri Feb 13, 2009 1:16 pm    Post subject: Reply with quote

DigitalCorpus wrote:
Well I just realized that adding sync to the mount options does effectively the same thing I spent the past few hours looking at trying to achieve :oops: :oops: . At least I learned a few things in the process :roll: :wink: .


does this sync thingy hurt throughput / performance a lot ?
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa

Hardcore Gentoo Linux user since 2004 :D
Back to top
View user's profile Send private message
DigitalCorpus
Apprentice
Apprentice


Joined: 30 Jul 2007
Posts: 245

PostPosted: Sat Feb 14, 2009 7:33 am    Post subject: Reply with quote

I'll have to do some test/benchmarks, but let me get a bootable system again :/

If you want to help head over here: https://forums.gentoo.org/viewtopic-t-736727.html
_________________
Atlas (HDTV PVR, HTTP & Media server)
http://atlas.selfip.net/Info/
Back to top
View user's profile Send private message
DigitalCorpus
Apprentice
Apprentice


Joined: 30 Jul 2007
Posts: 245

PostPosted: Mon Feb 16, 2009 9:42 am    Post subject: Reply with quote

:D :D Thanks for the help with udev :D :D

Before I go much farther into benchmarks and commenting on specific performance results of mounting tweaks, I'd like to finish correcting and setting configs and then evolve a cron based backup setup. Since I'm back to work no longer on vacation, this will take about another week :( .Stay tuned, but it might be some time before I can post back with anecdotal and bonnie++ benchmarks.


Oh, speaking of benchmarks. bonnie++ uses /dev/zero correct? how could I get it to use random data instead to get more reliable results with cryptcompress?
_________________
Atlas (HDTV PVR, HTTP & Media server)
http://atlas.selfip.net/Info/
Back to top
View user's profile Send private message
neuron
Advocate
Advocate


Joined: 28 May 2002
Posts: 2371

PostPosted: Mon Feb 16, 2009 11:15 am    Post subject: Reply with quote

Consider redoing my filesystems, currently "create=ccreg40,compress=lzo1", and I'm thinking of adding cluster size and fibration. I'm using r4 on root and $home, I dont have a seperate partition for compiling or /usr/portage (out of partitions, and I had some issues with lvm2 a few years ago which made me stop using it altogether). For $HOME I dont have any media files at all, I have a few tgz's of different directories, but it's mostly source code. I'm thinking of reducing the cluster size to 8k for latency, but I'm uncertain about fibration.

I see a lot of people using lexic_fibre, why? Whats the performance gain of sorting alphabetically? Wouldn't dot_o_fibre be "as fast" under normal conditions, and much faster when dealing with module loading on the fs? I dont see many scenarios where any software would need to read a lot of files in sequential alphabetical order, but loading *.o does seem fairly likely.

I'm a bit uncertain about compression algorithm as well, I dont care about how much space is used, only performance and latency (I have a 10 stage backup, which is copied to an offsite twice a month, the only data corruption that worries me are stealth ones). I'm on a 3.4ghz quad core, so I'm not overly worried about using cpu usage. I figure gzip should be faster shouldn't it? In more or less every scenario where I'm not maxing out all 4 cores? I figure the performance gained when reading gzip files (better compression) when the cpu's aren't maxed is more important than the small hit I'd take when all 4 cores are maxed.
Back to top
View user's profile Send private message
neuron
Advocate
Advocate


Joined: 28 May 2002
Posts: 2371

PostPosted: Mon Feb 16, 2009 11:50 am    Post subject: Reply with quote

kernelOfTruth wrote:
Quote:
for i in /sys/block/sd*; do
/bin/echo "cfq" > $i/queue/scheduler
/bin/echo "0" > $i/queue/iosched/slice_idle
/bin/echo "64" > $i/queue/iosched/quantum
done


and ideally (if you're having drives with ncq)
Code:
for i in /sys/block/sd*; do
         /bin/echo "1024" >  $i/queue/nr_requests
         /bin/echo "2" >  $i/device/queue_depth
done



I get the best results with them so far ...


I only have read only access to queue_depth, has that changed in recent kernels or something like that? It's 1, and wont change to 2.
Back to top
View user's profile Send private message
kernelOfTruth
Watchman
Watchman


Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)

PostPosted: Wed Feb 18, 2009 10:14 pm    Post subject: Reply with quote

neuron wrote:
kernelOfTruth wrote:
Quote:
for i in /sys/block/sd*; do
/bin/echo "cfq" > $i/queue/scheduler
/bin/echo "0" > $i/queue/iosched/slice_idle
/bin/echo "64" > $i/queue/iosched/quantum
done


and ideally (if you're having drives with ncq)
Code:
for i in /sys/block/sd*; do
         /bin/echo "1024" >  $i/queue/nr_requests
         /bin/echo "2" >  $i/device/queue_depth
done



I get the best results with them so far ...


I only have read only access to queue_depth, has that changed in recent kernels or something like that? It's 1, and wont change to 2.


you're by chance having an ide-drive or a raid-controller ?

then this can't be tweaked afaik :(

guys, guys - right now I'm getting some pretty wicked results :D

I'm backing up my data by writing to an middle-aged seagate harddrive (65 MB/s max throughput) and it's writing at 75-80 MB/s :twisted:

I'm using cryptcompress with gzip and rsync with -az option but this is sensational ! 8)

this drive never has been more useful than now !

let's see if it's only some faulty output of df ( :lol: ), iotop or really that fast

I'll then post my settings

hm, there sure is space for tweaking that filesystem :wink:
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa

Hardcore Gentoo Linux user since 2004 :D
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Unsupported Software All times are GMT
Goto page Previous  1, 2, 3, 4, 5  Next
Page 2 of 5

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum