| View previous topic :: View next topic |
| Author |
Message |
energyman76b
Advocate
Joined: 26 Mar 2003
Posts: 2045
Location: Germany
|
 Posted: Sat Oct 25, 2008 11:27 am Post subject: |
 |
|
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 |
|
 |
Yamakuzure
Advocate
Joined: 21 Jun 2006
Posts: 2277
Location: Bardowick, Germany
|
| Posted: Thu Oct 30, 2008 2:37 pm Post subject: |
|
|
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:- "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
- "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
|
|
| Back to top |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
| Posted: Thu Oct 30, 2008 2:48 pm Post subject: |
|
|
| 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  |
|
| Back to top |
|
|
Yamakuzure
Advocate
Joined: 21 Jun 2006
Posts: 2277
Location: Bardowick, Germany
|
| Posted: Thu Oct 30, 2008 3:03 pm Post subject: |
|
|
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:- "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
- "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
|
|
| Back to top |
|
|
energyman76b
Advocate
Joined: 26 Mar 2003
Posts: 2045
Location: Germany
|
| Posted: Thu Oct 30, 2008 4:40 pm Post subject: |
|
|
| 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 |
|
|
DigitalCorpus
Apprentice
Joined: 30 Jul 2007
Posts: 283
|
| Posted: Fri Oct 31, 2008 6:28 am Post subject: |
|
|
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://mobrienphotography.com/ |
|
| Back to top |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
| Posted: Sat Dec 27, 2008 11:28 am Post subject: |
|
|
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
Last edited by kernelOfTruth on Sat Dec 27, 2008 11:00 pm; edited 1 time in total |
|
| Back to top |
|
|
DigitalCorpus
Apprentice
Joined: 30 Jul 2007
Posts: 283
|
| Posted: Sat Dec 27, 2008 11:50 am Post subject: |
|
|
| 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://mobrienphotography.com/ |
|
| Back to top |
|
|
zyko
l33t
Joined: 01 Jun 2008
Posts: 620
Location: Munich, Germany
|
| Posted: Sat Dec 27, 2008 9:41 pm Post subject: |
|
|
| 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 |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
| Posted: Sat Dec 27, 2008 10:49 pm Post subject: |
|
|
| 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 ... 
_________________
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
Last edited by kernelOfTruth on Sat Dec 27, 2008 11:04 pm; edited 1 time in total |
|
| Back to top |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
| Posted: Sat Dec 27, 2008 10:59 pm Post subject: |
|
|
| 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  [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
Last edited by kernelOfTruth on Sat Dec 27, 2008 11:11 pm; edited 1 time in total |
|
| Back to top |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
| Posted: Sat Dec 27, 2008 11:06 pm Post subject: |
|
|
| 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 (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 
and those tbz2-packages take up more space (like you wrote) 
_________________
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 |
|
| Back to top |
|
|
tel
Tux's lil' helper
Joined: 15 Aug 2006
Posts: 112
|
| Posted: Wed Jan 07, 2009 5:42 pm Post subject: Another Reiser4 question |
|
|
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 |
|
|
nixnut
Bodhisattva
Joined: 09 Apr 2004
Posts: 10974
Location: the dutch mountains
|
| Posted: Wed Jan 07, 2009 5:54 pm Post subject: |
|
|
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 |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
| Posted: Wed Jan 07, 2009 8:11 pm Post subject: Re: Another Reiser4 question |
|
|
| 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 |
|
| Back to top |
|
|
energyman76b
Advocate
Joined: 26 Mar 2003
Posts: 2045
Location: Germany
|
| Posted: Wed Jan 07, 2009 9:48 pm Post subject: |
|
|
| 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 |
|
|
DigitalCorpus
Apprentice
Joined: 30 Jul 2007
Posts: 283
|
| Posted: Fri Jan 09, 2009 7:55 am Post subject: |
|
|
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 I have been using
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 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://mobrienphotography.com/ |
|
| Back to top |
|
|
DigitalCorpus
Apprentice
Joined: 30 Jul 2007
Posts: 283
|
| Posted: Mon Feb 09, 2009 10:47 am Post subject: Maximizing performance and adding some safety |
|
|
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://mobrienphotography.com/ |
|
| Back to top |
|
|
DigitalCorpus
Apprentice
Joined: 30 Jul 2007
Posts: 283
|
| Posted: Mon Feb 09, 2009 11:27 am Post subject: |
|
|
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  . At least I learned a few things in the process .
_________________
Atlas (HDTV PVR, HTTP & Media server)
http://mobrienphotography.com/ |
|
| Back to top |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
|
| Back to top |
|
|
DigitalCorpus
Apprentice
Joined: 30 Jul 2007
Posts: 283
|
|
| Back to top |
|
|
DigitalCorpus
Apprentice
Joined: 30 Jul 2007
Posts: 283
|
| Posted: Mon Feb 16, 2009 9:42 am Post subject: |
|
|
Thanks for the help with udev
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://mobrienphotography.com/ |
|
| Back to top |
|
|
neuron
Advocate
Joined: 28 May 2002
Posts: 2371
|
| Posted: Mon Feb 16, 2009 11:15 am Post subject: |
|
|
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 |
|
|
neuron
Advocate
Joined: 28 May 2002
Posts: 2371
|
| Posted: Mon Feb 16, 2009 11:50 am Post subject: |
|
|
| 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 |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
| Posted: Wed Feb 18, 2009 10:14 pm Post subject: |
|
|
| 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
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 
I'm using cryptcompress with gzip and rsync with -az option but this is sensational !
this drive never has been more useful than now !
let's see if it's only some faulty output of df (  ), iotop or really that fast
I'll then post my settings
hm, there sure is space for tweaking that filesystem
_________________
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 |
|
| Back to top |
|
|
|
|
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
|
|
Unsupported Software
