Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Some ext3 Filesystem Tips
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3 ... 6, 7, 8 ... 13, 14, 15  Next  
Reply to topic    Gentoo Forums Forum Index Documentation, Tips & Tricks
View previous topic :: View next topic  
Author Message
carpman
Advocate
Advocate


Joined: 20 Jun 2002
Posts: 2202
Location: London - UK

PostPosted: Sat Jan 07, 2006 12:47 am    Post subject: Reply with quote

Hello, i have just finised building a system using ext3 and tips given here, except /usr/src which i used reiserfs.

While compiling a number of app emerge stopped complaining of no space on 1.5gb /usr/portage partition, strange thought that would be enough.

I emptied /usr/portage/distfiles on this system and my notebook (reiserfs) to compare size:


Code:

Notebook, reiserfs /usr/portage = 175mb
New system ext3 /usr/portage = 580mb


Both of these are on own partitions.


I have to say that is big difference and if same across whole system is not good but suspect it is the many small files in portage, may change this partition to reiserfs.

Anyway rest o system is feeling nice and snappy
_________________
Work Station - 64bit
Gigabyte GA X48-DQ6 Core2duo E8400
8GB GSkill DDR2-1066
SATA Areca 1210 Raid
BFG OC2 8800 GTS 640mb
--------------------------------
Notebook
Samsung Q45 7100 4gb
Back to top
View user's profile Send private message
ruben
Guru
Guru


Joined: 04 Jul 2003
Posts: 462

PostPosted: Sat Jan 07, 2006 12:58 am    Post subject: Reply with quote

@carpman:
Could you tell us the block size on the ext3 system? (with dumpe2fs) You might want that to be 1024 bytes per block, that should save space with all the tiny files in /usr/portage.
Back to top
View user's profile Send private message
XenoTerraCide
Veteran
Veteran


Joined: 18 Jan 2004
Posts: 1418
Location: MI, USA

PostPosted: Sat Jan 07, 2006 5:18 am    Post subject: Reply with quote

/usr/portage/distfiles is 1.6 on mine
Code:
SLAVE-I ~ # du -sh /usr/portage/
2.1G    /usr/portage/
Back to top
View user's profile Send private message
carpman
Advocate
Advocate


Joined: 20 Jun 2002
Posts: 2202
Location: London - UK

PostPosted: Sat Jan 07, 2006 10:15 am    Post subject: Reply with quote

ruben wrote:
@carpman:
Could you tell us the block size on the ext3 system? (with dumpe2fs) You might want that to be 1024 bytes per block, that should save space with all the tiny files in /usr/portage.


Thanks for reply, here is first part output, take it you don't want all of it?

Code:

dumpe2fs /dev/vg/usrportage
dumpe2fs 1.38 (30-Jun-2005)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          0bb5438b-e4b2-4afc-90ee-2d304ccea4e2
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal dir_index filetype needs_recovery sparse_super
Default mount options:    journal_data
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              192000
Block count:              384000
Reserved block count:     19200
Free blocks:              229280
Free inodes:              58978
First block:              0
Block size:               4096
Fragment size:            4096
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         16000
Inode blocks per group:   500
Filesystem created:       Wed Jan  4 11:58:04 2006
Last mount time:          Sat Jan  7 00:09:43 2006
Last write time:          Sat Jan  7 00:09:43 2006
Mount count:              6
Maximum mount count:      37
Last checked:             Wed Jan  4 11:58:04 2006
Check interval:           15552000 (6 months)
Next check after:         Mon Jul  3 11:58:04 2006
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Journal inode:            8
Default directory hash:   tea
Directory Hash Seed:      810e1be4-fdec-4858-9225-a69341b0d545
Journal backup:           inode blocks

_________________
Work Station - 64bit
Gigabyte GA X48-DQ6 Core2duo E8400
8GB GSkill DDR2-1066
SATA Areca 1210 Raid
BFG OC2 8800 GTS 640mb
--------------------------------
Notebook
Samsung Q45 7100 4gb
Back to top
View user's profile Send private message
XenoTerraCide
Veteran
Veteran


Joined: 18 Jan 2004
Posts: 1418
Location: MI, USA

PostPosted: Sat Jan 07, 2006 10:21 am    Post subject: Reply with quote

I have a question for ruben so he can educate me... why did we ask carpmen for the output of dumpe2fs? couldn't we have gotten that information from
Code:
tune2fs -l /dev/xyz
? without all the crap dumpe2fs put's out.
Back to top
View user's profile Send private message
RuiP
l33t
l33t


Joined: 15 Jan 2005
Posts: 643

PostPosted: Sat Jan 07, 2006 11:20 am    Post subject: Reply with quote

XenoTerraCide wrote:
I have a question for ruben so he can educate me... why did we ask carpmen for the output of dumpe2fs? couldn't we have gotten that information from
Code:
tune2fs -l /dev/xyz
? without all the crap dumpe2fs put's out.


what thats for?

tune2fs -l output is short but I think carpman's computer should have resist the brutal impact of dumpe2fs ;)

carpman you can re-format your partition with a smaller block size to optimize space:
Code:
mke2fs -j -b 1024 /dev/whatever
Back to top
View user's profile Send private message
XenoTerraCide
Veteran
Veteran


Joined: 18 Jan 2004
Posts: 1418
Location: MI, USA

PostPosted: Sat Jan 07, 2006 11:26 am    Post subject: Reply with quote

I was curious... because I't more of a dumpe2fs being a cosmetic pain and I don't see anything that would be useful in this situation, for running dumpe2fs as opposed to tune2fs -l. I was hoping to learn something... but maybe there's nothing to learn? I do have a question though is there an advantage to using larger block sizes as opposed to smaller ones? because I would think smaller is better.
Back to top
View user's profile Send private message
RuiP
l33t
l33t


Joined: 15 Jan 2005
Posts: 643

PostPosted: Sat Jan 07, 2006 11:42 am    Post subject: Reply with quote

they have the same funcionality.
tune2fs -l is just an informative mode of runnig tune2fs, a tool that can made changes the parttions.
dumpe2fs is a tool to give only informationon a partition, but as much as possible. For the case, of course thats was not necessary...

to be picky, it's only need, for the case tune2fs -l /dev/hdxy | grep size

About size, it seems that larger block size gives better performance, but it takes more space. Much more. I have a 1G partition for /usr/portage and with default size 4096 it was 97% full, and block size =1024:
Code:
/dev/hda6              1059093    198935    806342  20% /usr/portage

portage is a very special case of forder tree. Thousands of very small files. It a special case, different of a regular linux root system or /home or /usr that could have all size files on it.
Back to top
View user's profile Send private message
carpman
Advocate
Advocate


Joined: 20 Jun 2002
Posts: 2202
Location: London - UK

PostPosted: Sat Jan 07, 2006 2:18 pm    Post subject: Reply with quote

RuiP wrote:
they have the same funcionality.
tune2fs -l is just an informative mode of runnig tune2fs, a tool that can made changes the parttions.
dumpe2fs is a tool to give only informationon a partition, but as much as possible. For the case, of course thats was not necessary...

to be picky, it's only need, for the case tune2fs -l /dev/hdxy | grep size

About size, it seems that larger block size gives better performance, but it takes more space. Much more. I have a 1G partition for /usr/portage and with default size 4096 it was 97% full, and block size =1024:
Code:
/dev/hda6              1059093    198935    806342  20% /usr/portage

portage is a very special case of forder tree. Thousands of very small files. It a special case, different of a regular linux root system or /home or /usr that could have all size files on it.


I think in this case reiserfs will be better, data on this partition is not an issue, same reason i have /usr/src as reiserfs.


cheers
_________________
Work Station - 64bit
Gigabyte GA X48-DQ6 Core2duo E8400
8GB GSkill DDR2-1066
SATA Areca 1210 Raid
BFG OC2 8800 GTS 640mb
--------------------------------
Notebook
Samsung Q45 7100 4gb
Back to top
View user's profile Send private message
ruben
Guru
Guru


Joined: 04 Jul 2003
Posts: 462

PostPosted: Sat Jan 07, 2006 5:06 pm    Post subject: Reply with quote

XenoTerraCide wrote:
I have a question for ruben so he can educate me... why did we ask carpmen for the output of dumpe2fs? couldn't we have gotten that information from
Code:
tune2fs -l /dev/xyz
? without all the crap dumpe2fs put's out.

dump2efs was overkill, the way you mention is clearly better. I was a bit in a hurry and just thought about dumpe2fs.
@carpman:
The example from RuiP makes clear why i asked. Small block size is important for /usr/portage. Still, the numbers from RuiP surprise me a bit though, i know it has a big impact, but block size 1024 and block size 4096.. partition size shouldn't differ more than a factor 4 i'd expect. (i'd expect a factor 4 in the 'worst' case: every file is smaller than a 1024 byte block) Maybe you also changed something else? (diminished amount of space reserved for root maybe?)
Back to top
View user's profile Send private message
carpman
Advocate
Advocate


Joined: 20 Jun 2002
Posts: 2202
Location: London - UK

PostPosted: Sat Jan 07, 2006 5:23 pm    Post subject: Reply with quote

ruben wrote:

dump2efs was overkill, the way you mention is clearly better. I was a bit in a hurry and just thought about dumpe2fs.
@carpman:
The example from RuiP makes clear why i asked. Small block size is important for /usr/portage. Still, the numbers from RuiP surprise me a bit though, i know it has a big impact, but block size 1024 and block size 4096.. partition size shouldn't differ more than a factor 4 i'd expect. (i'd expect a factor 4 in the 'worst' case: every file is smaller than a 1024 byte block) Maybe you also changed something else? (diminished amount of space reserved for root maybe?)


I just did as guide suggested, should note these were newly created not converted.

I am going to convert to reiserfs by moving data, converting and then moving it back to new FS, i am happy with it on other partitions just seems that when used with /usr/portage (usr/src) it may not be the best way forward.
_________________
Work Station - 64bit
Gigabyte GA X48-DQ6 Core2duo E8400
8GB GSkill DDR2-1066
SATA Areca 1210 Raid
BFG OC2 8800 GTS 640mb
--------------------------------
Notebook
Samsung Q45 7100 4gb
Back to top
View user's profile Send private message
RuiP
l33t
l33t


Joined: 15 Jan 2005
Posts: 643

PostPosted: Sat Jan 07, 2006 5:47 pm    Post subject: Reply with quote

ruben, you are right. Here is my values with same partition ans different block sizes:
1024:
Code:
/dev/hda6              1059093    198935    806342  20% /usr/portage

2048:
Code:
/dev/hda6              1059326    313058    692452  32% /usr/portage

4096:
Code:
/dev/hda6              1059360    561948    443596  56% /usr/portage


i was just saying from memory, but i decided to experiment with block sizes.

I remeber now, that my problem was not 99% full, but with a slight smaller partition i don't had enough space for portage.
It reported free space, but cp -a stop at middle complain about no space.

If i resize my partition to lower size then 1000000 and use default block size it will stop cp process copying most of files and report a no free space, but df and du will report yet a lot of free space !!
Even with that size if i make a new temp folder inside it and try co copy all /usr/portage/app-office to /usr/portage/temp it will report no free space enough altough it says it has 443596 available !!??

edit: oh, btw, i use ext2 (without journalizing) and tune2fs -O dir_index, on that partition.
Back to top
View user's profile Send private message
ruben
Guru
Guru


Joined: 04 Jul 2003
Posts: 462

PostPosted: Sun Jan 08, 2006 2:24 pm    Post subject: Reply with quote

RuiP wrote:
If i resize my partition to lower size then 1000000 and use default block size it will stop cp process copying most of files and report a no free space, but df and du will report yet a lot of free space !!
Even with that size if i make a new temp folder inside it and try co copy all /usr/portage/app-office to /usr/portage/temp it will report no free space enough altough it says it has 443596 available !!??

The numbers you get now are much more credible, but still show that it has a very big impact.
For what you mention about the free space, i can think about only one thing, and that's that you might run out of inodes when you make the partition smaller than 1000000. You could check that for sure with "df -i". One inode is needed for each directory and file. I don't know how mkfs.ext2 computes the default number of inodes for a partition, but say you have a block size of 4096 and all files fit in one block, then you'd want certainly as much inodes as the number of blocks you'll have. In general though, that'd be a waste of space, since typically most files will contain multiple blocks.
I just checked my root file system (ext3, but it's the same for ext2), and from the output of tune2fs:
Code:
Inode count:              917504
Block count:              1835008
Reserved block count:     18350
Free blocks:              115966
Free inodes:              613709

So.. it seems to have half as much inodes as blocks. And as you can see, I still have plenty of inodes left. But that'd mean that with tiny files, it might be worth it to increase the number of inodes when creating the file system (you can' change it afterwards).
I just check "df -i" on the same partition, and it gives me this:
Code:
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/hda4             917504  236996  680508   26% /

I wonder why it reports more inodes still available than tune2fs.
Back to top
View user's profile Send private message
XenoTerraCide
Veteran
Veteran


Joined: 18 Jan 2004
Posts: 1418
Location: MI, USA

PostPosted: Sun Jan 08, 2006 3:35 pm    Post subject: Reply with quote

hey codergeek can you add a part about the tune2fs -l in your howto?
Back to top
View user's profile Send private message
codergeek42
Bodhisattva
Bodhisattva


Joined: 05 Apr 2004
Posts: 5142
Location: Anaheim, CA (USA)

PostPosted: Sun Jan 08, 2006 5:38 pm    Post subject: Reply with quote

XenoTerraCide wrote:
hey codergeek can you add a part about the tune2fs -l in your howto?
Good idea. I've added that to the end of my guide. Thanks. :)
_________________
~~ Peter: Programmer, Mathematician, STEM & Free Software Advocate, Enlightened Agent, Transhumanist, Fedora contributor
Who am I? :: EFF & FSF
Back to top
View user's profile Send private message
RuiP
l33t
l33t


Joined: 15 Jan 2005
Posts: 643

PostPosted: Sun Jan 08, 2006 6:57 pm    Post subject: Reply with quote

Hello ruben,
you were right, i run out of free inodes.
My results with the 1G partition with -b 1024 default number of inodes:
Code:
Inode count:              135168
Block count:              1076320
Reserved block count:     53816
Free blocks:              859976
Free inodes:              1952

so with block size of 4096 it should have even less...
My previous experiments with smaller partition sizes going always to out of space when space was detected by df was more certain caused by this.

Here is the new results with default block size (4096) and inode count raised by 50%, on same partition:
Code:
Inode count:              202752
Block count:              269080
Reserved block count:     13454
Free blocks:              122109
Free inodes:              69536

that is 35x more free inodes with block size 4x higher!
Thanks for your suggestion.

I wander if there is some penalty for raising the inode numbers?...
Back to top
View user's profile Send private message
wrc1944
Advocate
Advocate


Joined: 15 Aug 2002
Posts: 3271
Location: Gainesville, Florida

PostPosted: Mon Jan 09, 2006 7:59 am    Post subject: Reply with quote

Thought I'd post a link to an update of the LinuxGazette File system tests- I was one of people who emailed Justin and asked him to re-run his great tests with a new kernel (He used 2.6.14.4 for these). Apparently, I guess he used a default ext3, not using the dir_index and data=writeback (or journal_data) modes. I just changed all my Gentoo boxes to ext3 from reiserfs (with the ext3 tweaks), so I'd really be interested in having his tests run with those ext3 options, and see if there is significant improvement.

http://linuxgazette.net/122/piszcz.html

A quick perusal of these new tests indicate that:

On test 001 (touch 10,000 files) ext2/3 lag way behind. (perhaps the default commit interval of 5 seconds is the cause- mine is set to 600 seconds).

On test 004 (make 10,000 directories), again ext2/3 lag way behind.

Table for test 015 (split a 10mb file into 1000/1024/2048/4096/8192 size byte pieces (fixed). (Graph makes differences much more striking).

ext2 ext3 JFS R3 R4 XFS
015 Split 10M File into 1000 Byte Pieces 57.26 57.77 2.99 4.35 2.95 4.87
016 Split 10M File into 1024 Byte Pieces 28.73 28.97 2.24 4.04 2.61 4.01
017 Split 10M File into 2048 Byte Pieces 7.02 6.98 1.39 2.26 1.55 1.95
018 Split 10M File into 4096 Byte Pieces 1.85 1.83 0.67 1.05 0.99 0.98
019 Split 10M File into 8192 Byte Pieces 0.58 0.58 0.36 0.56 0.62 0.57

At 4096 and 8192 bytes, ext2/3 essentially equal all the others, but drastically lag performance-wise below that size (maybe a block size tweak for certain circumstances would improve this?)

On the 18 other tests, ext2/3 equals or beats all the other file systems. I'm assuming this is with ext3 defaults (for what they're worth). All 21 tests are also listed as cpu usage. Unfortunately, there was no very small file test, and I still think reiserfs might be significantly better for a dedicated /usr/portage partition, and I'll probably set that up next on all my systems

More FS info at Gentoo the slow down thread.
https://forums.gentoo.org/viewtopic-p-3016647.html#3016647
_________________
Main box- AsRock x370 Gaming K4
Ryzen 1700, 3.0GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
Gentoo ~amd64 plasma, glibc-2.30-r2, gcc-9.2.0 kernel-5.4.1-gentoo USE=experimental
Back to top
View user's profile Send private message
wrc1944
Advocate
Advocate


Joined: 15 Aug 2002
Posts: 3271
Location: Gainesville, Florida

PostPosted: Thu Jan 12, 2006 6:39 am    Post subject: Reply with quote

I just ran across this brand new 2.6.15 multiple block allocation to current ext3 patch. Anyone else know more about this, or have any experiences to share?

http://lwn.net/Articles/167266/

I just had compiled a new 2.6.15-ck1 kernel, but this ext3 patch looked so good after googling up on what they are talking about, I had to try it. I noticed it had been included in 2.6.15-mm3, so I went ahead and tried mm3.

It definitely seems to have snappier desktop responsiveness than ck1 does, and ck1 is great, too. No benchmarks from my systems- just my subjective impressions, but I'm not one to hype up a placebo effect. Wish I had first tried recompiling ck1 with the ext3 patch added, so I'd really know if it wasn't just the mm3 stuff instead of the ext3 multiple block allocation patch.

I will definitely (try to) incorporate it into all kernels I build that don't have it from now on.
_________________
Main box- AsRock x370 Gaming K4
Ryzen 1700, 3.0GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
Gentoo ~amd64 plasma, glibc-2.30-r2, gcc-9.2.0 kernel-5.4.1-gentoo USE=experimental
Back to top
View user's profile Send private message
ruben
Guru
Guru


Joined: 04 Jul 2003
Posts: 462

PostPosted: Thu Jan 12, 2006 3:19 pm    Post subject: Reply with quote

RuiP wrote:
I wander if there is some penalty for raising the inode numbers?...

I think the only penalty is a bit more space "wasted" on the inodes.
wrc1944 wrote:
Thought I'd post a link to an update of the LinuxGazette File system tests...

It would be interesting to see the same benchmarks but with the "dir_index" optimisation. Tests 1, 4 & 15 all indicate that creating thousands of files in 1 directory is expensive. I think that creating a new file in a directory becomes more expensive as there are more files already in that directory. With the "dir_index" option, this should become cheaper. The question is whether this will make other operations more expensive.
Back to top
View user's profile Send private message
XenoTerraCide
Veteran
Veteran


Joined: 18 Jan 2004
Posts: 1418
Location: MI, USA

PostPosted: Thu Jan 12, 2006 4:22 pm    Post subject: Reply with quote

I have new news on how much faster putting /usr/portage in it's own partition with a block size 1024, on ext3 with data=journal, and dir_index, as opposed to part of the / filesystem with 4096, same options.

I have a laptop with a 4200 RPM HD. the HD is so slow it decrease's the computer's performance. but it's the one with /usr/portage in it's own dir. my desktop has a 7200 rpm sata. started within second's of each other the laptop beat the desktop on emerge sync by minutes. I didn't time it but I was amased. however I will say the laptop has a faster processor by far (athlon-xp 22000 vs athlon64 3200) so that may have a lot to do with it... depending on how much the processor is used to build the cache.
_________________
I don't hang out here anymore, try asking on http://unix.stackexchange.com/ if you want my help.
Back to top
View user's profile Send private message
wrc1944
Advocate
Advocate


Joined: 15 Aug 2002
Posts: 3271
Location: Gainesville, Florida

PostPosted: Thu Jan 12, 2006 7:16 pm    Post subject: Reply with quote

XenoTerraCide,
Thanks for the info. Is this partition actually just the usr/portage directory itself, or the entire /usr on the partition, and what size (GB) is it?

I just moved my entire portage tree to a 3GB reiserfs partition for small file performance (portage directory only on /mnt/portage, hda6), and also /var and /tmp to their own partitions (ext3, dir_index, data=writeback, 4096). I notice a good improvement also.

In your case, I guess it's hard to figure how much effect slow drive/fast 64bit cpu/board vs. faster drive/slower 32bit cpu/board has.

I'll have to investigate the 1024 block size more as related to partition size. I guess that would be good for really small files, but what about the much larger files in distfiles?

I guess the question would be does the 1024 block and ext3 options equal or closely approach reiserfs small file performance?

Another interesting point: IMO there's no real need for journaling on a dedicated portage partition, so why not disable it and save the overhead, either on ext3 or reiserfs? Seems like that would also help performance.
_________________
Main box- AsRock x370 Gaming K4
Ryzen 1700, 3.0GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
Gentoo ~amd64 plasma, glibc-2.30-r2, gcc-9.2.0 kernel-5.4.1-gentoo USE=experimental
Back to top
View user's profile Send private message
XenoTerraCide
Veteran
Veteran


Joined: 18 Jan 2004
Posts: 1418
Location: MI, USA

PostPosted: Thu Jan 12, 2006 7:33 pm    Post subject: Reply with quote

I think reiser is faster. but I had files small ones disappear in reiser so I went with ext3. and it's just /usr/portage. 2.5G Partion. du says 1.2 G is being used that's an improvement from 2.1 on my desktop.
_________________
I don't hang out here anymore, try asking on http://unix.stackexchange.com/ if you want my help.
Back to top
View user's profile Send private message
RuiP
l33t
l33t


Joined: 15 Jan 2005
Posts: 643

PostPosted: Thu Jan 12, 2006 10:09 pm    Post subject: Reply with quote

Hi, guys.
I'm in the feeling that i induce some of you to wrong conclusions.
The suggestion to go for smaller blocks was to get more space or even space enough. Not to improve performance.
In theory, i think, larger block size should improve performance.
Anyway, as ruben so well pointed, raising the numbers of inodes will allow for a much better use of space with the default block size (for portage tree of course).

XenoTerraCide, you say your /usr/partition is 1.2 of 2.5G. That's strange. Do you have /distfiles dir inside /usr/portage?
That's is, imho, one of the major nonsenses of portage design. Mix a dir with large files with dir with thousand miscroscopic files is insane!
If you move /distfile to another partition (i use one with xfs) and make a link from /usr/portage or change the variable path at /etc/make.conf will result in a much less fragmented file system and you could go back to the 4096 block size and use a partition of something small as 0.6G.
mine is
Code:
Filesystem    Size  Used  Avail  Use% Mounted on
/dev/hda6     713M  553M  124M  82% /usr/portage


About benchmark performance, emerge sync is probabily the worst think one could try. And one time test is meaningless. It depends on too much things. Server/mirror speed, connection/net speed, state of portage trees (older => slower), number of updates available (weekends =>faster =>developers need to rest :)), the random screensaver that starts in the middle of resync was the harder cpu eater or the lighter, etc...
For a while i take notes of times, to make some statistic, till i realize i was being stupid.
emerge.log has all information i need, for long times.
I have logs since september 04. So i do a quick spreadsheet.
Jan 05 till Ago 05 i used reiserfs portage inside system with only a separate partition for distfile (and the usual /boot and /home too, irrelevant for this). I sync 155 times
from Sep 05 till Dec 05 i use a separated /usr/portage, ext2 (no journalizing) with block size 1024 and dir_index option. Sync 55 times.
Here are my average results:
Code:
resiserfs: 2mn 47sec.
ext2: 2mn 11sec.

I don't think that small difference has any meanning. Equal speed.
(in a month or two i'll redo with my new ext2 block size=4096. I don't expect much diference anyway...)

Since i was testing something that could have huge flutuations, but could easily been simulated under better controlled conditions, i tried another test. emerge sync is just a rsync of files over net plus extra resync with metadata cache.
So i do a overforced test, resync a full tree of an existing portage on my original partition to several small partitions with diferent files systems.
Do it 3 times after reboots, (to avoid linux caches the files tree)
Results (averages):
Code:
|reiserfs |  2m 30s  |
|ext3     |  2m 22s  |
|ext2     |  1m 25s  |
|xfs     |  4m 10s  |

Again reiserfs and ext3 take more or less the same, ext2 almost 1/2 time, and xfs with no surprises shows that it's not a good choice for the case.
Hope this is of any use, or at least interesting.

edit: oops, i typed dates contractions in portuguese, corrected now.


Last edited by RuiP on Thu Mar 23, 2006 2:47 pm; edited 2 times in total
Back to top
View user's profile Send private message
codergeek42
Bodhisattva
Bodhisattva


Joined: 05 Apr 2004
Posts: 5142
Location: Anaheim, CA (USA)

PostPosted: Thu Jan 12, 2006 10:12 pm    Post subject: Reply with quote

wrc1944 wrote:
Another interesting point: IMO there's no real need for journaling on a dedicated portage partition, so why not disable it and save the overhead, either on ext3 or reiserfs? Seems like that would also help performance.
Firstly, the point I mentioned was tha full journalling is supposed to, in fact, increase performance on such partitions which have a lot of virtuallty simultaneous reads/writes. Secondly, there is no way that I am aware of to disable journalling in ReiserFS. :)
_________________
~~ Peter: Programmer, Mathematician, STEM & Free Software Advocate, Enlightened Agent, Transhumanist, Fedora contributor
Who am I? :: EFF & FSF
Back to top
View user's profile Send private message
XenoTerraCide
Veteran
Veteran


Joined: 18 Jan 2004
Posts: 1418
Location: MI, USA

PostPosted: Thu Jan 12, 2006 10:30 pm    Post subject: Reply with quote

no putting portage in it's own partition is supposed to increase performance. the 1024 was to save space but I wasn't sure how much.
_________________
I don't hang out here anymore, try asking on http://unix.stackexchange.com/ if you want my help.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Documentation, Tips & Tricks All times are GMT
Goto page Previous  1, 2, 3 ... 6, 7, 8 ... 13, 14, 15  Next
Page 7 of 15

 
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