| View previous topic :: View next topic |
| Please READ the tables,next for which fs You want to switch ? :) |
| ext3 |
|
26% |
[ 68 ] |
| jfs |
|
10% |
[ 26 ] |
| reiser3 |
|
17% |
[ 44 ] |
| reiser4 |
|
35% |
[ 91 ] |
| xfs |
|
9% |
[ 25 ] |
|
| Total Votes : 254 |
|
| Author |
Message |
codergeek42
Bodhisattva
Joined: 05 Apr 2004
Posts: 5142
Location: Anaheim, CA (USA)
|
 Posted: Mon Apr 18, 2005 4:55 pm Post subject: |
 |
|
| IvanYosifov wrote: | | Quote: |
If by 'some things other filesystems can't do' you mean atomic opperations there's no point here, since operations would only be atomic with the necesary hardware support, that, as far as i'm aware do not exist.
|
I somewhat doubt this argument. If no atomicity could be achived what is all the fuzz about journalling ? My system has come up back intact from every abrupt shutdown/reboot. Why is that ? Pure luck ? |
That's exactly it. If every filesystem operation was atomic down to the hardware level there would be no need for journalling. Journalling overcomes this by keeping a log of transactions that, if the filesystem is not unmounted cleanly, can be replayed onto the filesystem to keep it in a consistent state.
_________________
~~ Peter: Brony, GNU/Linux geek, caffeine addict, and Free Software advocate.
Who am I? :: EFF & FSF |
|
| Back to top |
|
 |
IvanYosifov
l33t
Joined: 15 Oct 2004
Posts: 778
Location: Bulgaria
|
| Posted: Mon Apr 18, 2005 5:04 pm Post subject: |
|
|
| Quote: |
If every filesystem operation was atomic down to the hardware level there would be no need for journalling
|
I don't think so. Logical vs hardware operations. Suppose single-byte writes were atomic. A normal metadata update involves many single-byte writes, and if power goes down in the middle you end up with broken metadata on atomic hardware. |
|
| Back to top |
|
|
codergeek42
Bodhisattva
Joined: 05 Apr 2004
Posts: 5142
Location: Anaheim, CA (USA)
|
| Posted: Mon Apr 18, 2005 5:07 pm Post subject: |
|
|
That's why I said "if every transaction," not merely every written byte. 
Edit: Oh wait. I didn't actually say that. But I meant that! 
_________________
~~ Peter: Brony, GNU/Linux geek, caffeine addict, and Free Software advocate.
Who am I? :: EFF & FSF |
|
| Back to top |
|
|
IvanYosifov
l33t
Joined: 15 Oct 2004
Posts: 778
Location: Bulgaria
|
| Posted: Mon Apr 18, 2005 5:12 pm Post subject: |
|
|
| Quote: |
Edit: Oh wait. I didn't actually say that. But I meant that!
|
Happens sometimes
Ok, and why should the journalling fail if writes are not atomic ? |
|
| Back to top |
|
|
i92guboj
Moderator
Joined: 30 Nov 2004
Posts: 9464
Location: Córdoba (Spain)
|
| Posted: Mon Apr 18, 2005 5:24 pm Post subject: |
|
|
Well, if you know something about the x86 architecture you will also know that every disk write opperation has at least the need of three single ops, even the most basic writing.
1.- Load the correct values in the relevant registers to specify what you wanna write.
2.- Load the correct values in the relevant registers to specify the number of funtion, previous to the writing operation.
2.- Call the interruption it selft.
THIS is the basic writing, of course a fs need much more than this to write a single byte to a file, because you need also the update the inodes and many other info in the medium you are writing to.
So the atomicity is just imposible. Does not matter what reiser4 at all to me. They can always define atomicity with any other words, but the real definition of 'atom' is 'indivisible thing' and any write opp in x86 is divisible, meaning that the operations can be interrupted without being finished completely.
The fact that reiser4 make operations and transactions in a simpler and in any way a 'more atomic way' does not mean that reiser4 is really an atomic operations based filesystem. Just my opinion, of course.
_________________
Gentoo Handbook | My website |
|
| Back to top |
|
|
yardbird
l33t
Joined: 20 Apr 2002
Posts: 688
Location: nl.leiden
|
| Posted: Mon Apr 18, 2005 5:38 pm Post subject: |
|
|
| petrjanda wrote: | | Those features are NOT innovative, and have never worked correctly, and use too much CPU. |
Well, considering that they reworked the whole concept of "file", the fact that they broke just two (2) applications seems like a good achievement to me (and BTW it was the apps' fault). You would have done better I guess? Also I would like to know which fs implements the reiser4 features you find "not innovative". Finally I find rather amusing all this buzz about high CPU usage. The bottleneck in every modern PC is at the hard-disk level, not certainly at the CPU level. With today's processors there is almost no connection between CPU usage and transfer rate.
| petrjanda wrote: | | I won't submit anything to reiserfs list, because I don't support Hans's way of doing things, and his attitude. |
Ah, ok, this explains a lot of stuff...
| petrjanda wrote: | | Of course you can read horror stories on pretty much every fs out there, but reiser4 is the only one called "final" by its creator while in reality its not even RC ready. |
Look, for all the QA you can do you reach the point where you have to release it to the public to receive more testing and squash bugs. The same thing Linus usually does BTW (remember the early 2.4.x kernels?), with the difference that there are much more hackers working on the kernel.
What I see from you is a lot of ad hominem and lack of solid arguments.
| Quote: | | 1.- I dont think they have acomplished what they promissed at all. If by 'some things other filesystems can't do' you mean atomic opperations there's no point here, since operations would only be atomic with the necesary hardware support, that, as far as i'm aware do not exist. |
Mh, what do you mean? Reiser4 operations are atomic. Beside there's much more than atomic operations: online repacker, plugin architecture, enhanced security...
_________________
| Albert Einstein wrote: | | I consider it [...] urgently necessary for [...] workers to get together, both to protect their own economic status and [...] to secure their influence in the political field. |
http://www.bluescarni.info |
|
| Back to top |
|
|
IvanYosifov
l33t
Joined: 15 Oct 2004
Posts: 778
Location: Bulgaria
|
| Posted: Mon Apr 18, 2005 5:49 pm Post subject: |
|
|
| Quote: |
Well, if you know something about the x86 architecture
|
If I knew how the writing process worked, we would no be having this conversation
| Quote: |
1.- Load the correct values in the relevant registers to specify what you wanna write.
2.- Load the correct values in the relevant registers to specify the number of funtion, previous to the writing operation.
2.- Call the interruption it selft.
|
Thanks for the clarification.
| Quote: |
So the atomicity is just imposible. Does not matter what reiser4 at all to me. They can always define atomicity with any other words
|
Then this is just a big misunderstanding. Atomicity as you see it is impossible. What any journalled fs promisses is logical atomicity. Different type of atomicity. |
|
| Back to top |
|
|
spb
Retired Dev
Joined: 02 Jan 2004
Posts: 2135
Location: Cambridge, UK
|
| Posted: Mon Apr 18, 2005 5:56 pm Post subject: |
|
|
| yardbird wrote: | | petrjanda wrote: | | Those features are NOT innovative, and have never worked correctly, and use too much CPU. |
Well, considering that they reworked the whole concept of "file", the fact that they broke just two (2) applications seems like a good achievement to me (and BTW it was the apps' fault). |
They broke more than 2 applications, and most of those were relying on well-documented standard file semantics.
| Quote: | | The bottleneck in every modern PC is at the hard-disk level, not certainly at the CPU level. With today's processors there is almost no connection between CPU usage and transfer rate. |
That depends entirely on the workload. |
|
| Back to top |
|
|
i92guboj
Moderator
Joined: 30 Nov 2004
Posts: 9464
Location: Córdoba (Spain)
|
| Posted: Mon Apr 18, 2005 6:02 pm Post subject: |
|
|
Even at logical level, the concepts of filesystem and atomicity are just incompatible. The only writing operations that would be atomic in this sense (without count the hardware based atomicity) would be the writing to a tape, without filesystem.
All the filesystems need to have two separated stages: first the writing of the data, second: the update of the relevant structures that supports, index, and provides acces to the data, whichever it is (table, tree, or a supermegafashion database) does not matter at all, since all of them breaks atomicity. To say more, this systems has also the thing of journalling. Don't missunderstand me: I think that journals ara a good thing, but here we are talking about atomicity, and no journaled filesystem can promise that whitout telling us a lie.
If fact no filesystem can promise that. The only thing I really like in the concept about reiser4 is the plugins architecture, but for now, and untill it develops and reach something near a mature state that is just an uselles thing.
_________________
Gentoo Handbook | My website |
|
| Back to top |
|
|
i92guboj
Moderator
Joined: 30 Nov 2004
Posts: 9464
Location: Córdoba (Spain)
|
| Posted: Mon Apr 18, 2005 6:13 pm Post subject: |
|
|
| spb wrote: | | yardbird wrote: | | petrjanda wrote: | | Those features are NOT innovative, and have never worked correctly, and use too much CPU. |
Well, considering that they reworked the whole concept of "file", the fact that they broke just two (2) applications seems like a good achievement to me (and BTW it was the apps' fault). |
They broke more than 2 applications, and most of those were relying on well-documented standard file semantics.
| Quote: | | The bottleneck in every modern PC is at the hard-disk level, not certainly at the CPU level. With today's processors there is almost no connection between CPU usage and transfer rate. |
That depends entirely on the workload. |
Fully agree. And I add: I tested reiser4, so I'm not talking just by suppositions. The harddisk is one of the slowest devices, that comes by the fact that, in the best cases the mechanic devices can have an access time messured in milisecond, while the electronic devices have one meassured in nanosecond, or even less.
This fact of course make the mechanic devices three magnitude orders (or even more) less fast than the microchips. How can you think that a filesystem can have a relevant effect on this? It would be like traying to kill an elephant with an army of carey turtles.
The only fact I can talk about is that reiser4 raises the cpu activity to levels that are not acceptable. In a desktop for interactivity loss, and in a server for that you don't know when will the system load grow, it can be in any momment.
_________________
Gentoo Handbook | My website |
|
| Back to top |
|
|
yardbird
l33t
Joined: 20 Apr 2002
Posts: 688
Location: nl.leiden
|
| Posted: Mon Apr 18, 2005 6:19 pm Post subject: |
|
|
| 6thpink wrote: | | All the filesystems need to have two separated stages: first the writing of the data, second: the update of the relevant structures that supports, index, and provides acces to the data, whichever it is (table, tree, or a supermegafashion database) does not matter at all, since all of them breaks atomicity. |
Ok, I agree with you on this. But as I understand it the concept of "atomicity" is not that of issuing an atomic command, but to ensure that a transaction was (or wasn't) really performed. Yes there are corner cases in which such a thing cannot be determined 100%, but making sure that a filesystem performs such checks in all its calls can greatly reduce the risk of losing data. Forgive me if I'm not more "technical" (I couldn't anyway )
| sbp wrote: | | They broke more than 2 applications, and most of those were relying on well-documented standard file semantics. |
But then I wonder why _all_ applications did not break. I remember the case of Apache2, which broke because it used a not-very-standard way to check if an object is a dir or a file (IIRC, feel free to correct me). When you change such low-level stuff it is inevitable that you end up breaking something, it surprised me that the breakage was so confined.
_________________
| Albert Einstein wrote: | | I consider it [...] urgently necessary for [...] workers to get together, both to protect their own economic status and [...] to secure their influence in the political field. |
http://www.bluescarni.info |
|
| Back to top |
|
|
IvanYosifov
l33t
Joined: 15 Oct 2004
Posts: 778
Location: Bulgaria
|
| Posted: Mon Apr 18, 2005 6:32 pm Post subject: |
|
|
| Quote: |
Yes there are corner cases in which such a thing cannot be determined 100%, but making sure that a filesystem performs such checks in all its calls can greatly reduce the risk of losing data. Forgive me if I'm not more "technical" (I couldn't anyway )
|
I think this is pretty exact. Apart from replaying transactions, a job of the journalling code is to run an local-fsck on parts of the fs which , given the operations log , may have been corrupted. If this is not done, it is an fs bug.
| Quote: |
They broke more than 2 applications, and most of those were relying on well-documented standard file semantics.
|
So did NPTL ( vs Linuxthreads ). There simply is a point where you have to real-world test your code, see what breaks and if you should fix it or start over. IMO, reiser4 is at this very point and is way too early to draw conclusions. |
|
| Back to top |
|
|
i92guboj
Moderator
Joined: 30 Nov 2004
Posts: 9464
Location: Córdoba (Spain)
|
| Posted: Mon Apr 18, 2005 6:34 pm Post subject: |
|
|
| yardbird wrote: | | 6thpink wrote: | | All the filesystems need to have two separated stages: first the writing of the data, second: the update of the relevant structures that supports, index, and provides acces to the data, whichever it is (table, tree, or a supermegafashion database) does not matter at all, since all of them breaks atomicity. |
Ok, I agree with you on this. But as I understand it the concept of "atomicity" is not that of issuing an atomic command, but to ensure that a transaction was (or wasn't) really performed. Yes there are corner cases in which such a thing cannot be determined 100%, but making sure that a filesystem performs such checks in all its calls can greatly reduce the risk of losing data. Forgive me if I'm not more "technical" (I couldn't anyway )
| sbp wrote: | | They broke more than 2 applications, and most of those were relying on well-documented standard file semantics. |
But then I wonder why _all_ applications did not break. I remember the case of Apache2, which broke because it used a not-very-standard way to check if an object is a dir or a file (IIRC, feel free to correct me). When you change such low-level stuff it is inevitable that you end up breaking something, it surprised me that the breakage was so confined. |
I agree with you that, in concept, the idea which suposedly is reiser4 is a good thing. But I truly think that they have not reached the level of atomicity or security they wanted, still. I know that I may appear to be a bit rude when talking about reiser4, but have spend so much awfull evening trying to repair fs-massacres.
Maybe, the point here is the maturity of the code. Really, do you think that reiser4 is ready for a production system yet? I don't think so, it is still far from perfect. It is also true that there is no perfect fs, but we have to guide thru statistics, and listening to them, reiser4 is, for now, the most unstable fs out here.
I don't know if it will improve one day. I pray for it, would be pleased to be wrong and have to eat my own words if I am able to see a faster and more confiable fs, but it is a hard thing to do.
As I said in some other post (dont remember if here or there...): if such a thing like a revolutionary fs would exist their owners would be rich, and would be right now in the beachs of Hawai. Such a thing would be like make something better than quicksort for lists, in a world where the filesystems had been left appart so many years.
We are using so old technology in this area, so we are doing too in fixed storage devices, really.
Btw, u like pink floyd? (say for your ubication info, if thats the case, here I agree with you  )
_________________
Gentoo Handbook | My website |
|
| Back to top |
|
|
IvanYosifov
l33t
Joined: 15 Oct 2004
Posts: 778
Location: Bulgaria
|
| Posted: Mon Apr 18, 2005 6:50 pm Post subject: |
|
|
| Quote: |
Really, do you think that reiser4 is ready for a production system yet?
|
At least I , as stated a few pages ago, do not  |
|
| Back to top |
|
|
fallow
Bodhisattva
Joined: 08 Jan 2004
Posts: 2206
Location: Poland
|
| Posted: Mon Apr 18, 2005 10:28 pm Post subject: |
|
|
| yarbird wrote: | | The bottleneck in every modern PC is at the hard-disk level, not certainly at the CPU level. With today's processors there is almost no connection between CPU usage and transfer rate. |
using fs is not only transfer rate or troughput , there are other ascpects that making the interactivity of rest of the system also.
of course are many of direct and in-direct reasons , but then how You explain %CP=98 for reiser4/3 and %CP=11 for JFS , states in this table ? operations are the same
| Code: |
Version 1.93c ------Sequential Create------ --------Random Create--------
Enterprise -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
reiser4 16 17829 90 +++++ +++ 8190 98 8174 95 +++++ +++ 8307 98
reiser3 16 11570 89 +++++ +++ 10999 98 11402 91 +++++ +++ 9970 98
jfs 16 3569 16 +++++ +++ 2177 11 1349 17 +++++ +++ 1023 9
xfs 16 2461 35 +++++ +++ 2203 27 2429 35 +++++ +++ 884 13
ext3 16 816 98 +++++ +++ 24692 77 780 97 +++++ +++ 2256 96
|
cheers 
_________________
"Time is a companion that goes with us on a journey. It reminds us to cherish each moment, because it will never come again. What we leave behind is not as important as how we have lived" J-L. Picard |
|
| Back to top |
|
|
Sith_Happens
Veteran
Joined: 15 Dec 2004
Posts: 1807
Location: The University of Maryland at College Park
|
| Posted: Mon Apr 18, 2005 11:12 pm Post subject: |
|
|
Unless I'm reading that chart wrong though, It seems there is also a serious performance hit involved in that decrease in cpu use.
_________________
"That question was less stupid; though you asked it in a profoundly stupid way."
I'm the brains behind Jackass! | Tutorials: Shorewall |
|
| Back to top |
|
|
i92guboj
Moderator
Joined: 30 Nov 2004
Posts: 9464
Location: Córdoba (Spain)
|
| Posted: Mon Apr 18, 2005 11:37 pm Post subject: |
|
|
| fallow wrote: | ...but then how You explain %CP=98 for reiser4/3 and %CP=11 for JFS , states in this table ? operations are the same
| Code: |
Version 1.93c ------Sequential Create------ --------Random Create--------
Enterprise -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
reiser4 16 17829 90 +++++ +++ 8190 98 8174 95 +++++ +++ 8307 98
reiser3 16 11570 89 +++++ +++ 10999 98 11402 91 +++++ +++ 9970 98
jfs 16 3569 16 +++++ +++ 2177 11 1349 17 +++++ +++ 1023 9
xfs 16 2461 35 +++++ +++ 2203 27 2429 35 +++++ +++ 884 13
ext3 16 816 98 +++++ +++ 24692 77 780 97 +++++ +++ 2256 96
|
cheers |
Btw, which is the program you used to test this thing? I would like to try on some radically different machines to see what can I work out of this. I have so much time to get bored.
_________________
Gentoo Handbook | My website |
|
| Back to top |
|
|
petrjanda
Veteran
Joined: 05 Sep 2003
Posts: 1557
Location: Brno, Czech Republic
|
| Posted: Tue Apr 19, 2005 12:34 am Post subject: |
|
|
| IvanYosifov wrote: | | Quote: |
Those features are NOT innovative
|
That means I have them today ?
|
Question should be, does anyone but Hans Ricer fanboys need them?
| Quote: |
Features don't use any CPU. Implementations do. You have to start somewhere, and the first attempt is never the final one.
|
Don't give me these wordplays. Hans's implementation of these things is broken!
I take it you never read articles on lkml, and you never read how he replies to objections given to him and the way he implements the features? google on silent semantic changes. Always has to get things done his way, and then its broken.
| Quote: |
Can you picture an fs development process that allows a company with a dozen programmers and a limited set of test hardware to develop an fs that runs flawlessly on all hardware ?
|
I can picture such code not to be released to wide public saying its final before a large group of people who personally asked namesys to be allowed to beta test it can say "it's stable". Then we won't hear these "ooooh oooh cry oooh reiser killed my computer and all my data, oooh", stupidity of these ricers is beyond my comprehension.
| Quote: |
In case someone has not understood this allready: reiser4 is still in development. In both code-debugging and design-debugging. It as final as Linux 2.6.0 was ! It is at the point where it needs mass testing. You don't feel like risking your data in the name of an fs ? Great ! Neither do I ! This does not mean I will not use it once it goes really stable.
|
Except Linux 2.6 doesn't eat all your data. You dont release fs code to whoever, these people don't even submit bug reports.
_________________
There is, a not-born, a not-become, a not-made, a not-compounded. If that unborn, not-become, not-made, not-compounded were not, there would be no escape from this here that is born, become, made and compounded. - Gautama Siddharta |
|
| Back to top |
|
|
fallow
Bodhisattva
Joined: 08 Jan 2004
Posts: 2206
Location: Poland
|
| Posted: Tue Apr 19, 2005 6:16 am Post subject: |
|
|
6thpink : this is bonnie++ (in portage)
cheers
_________________
"Time is a companion that goes with us on a journey. It reminds us to cherish each moment, because it will never come again. What we leave behind is not as important as how we have lived" J-L. Picard |
|
| Back to top |
|
|
superstoned
Guru
Joined: 17 Dec 2004
Posts: 430
|
| Posted: Tue Apr 19, 2005 8:37 am Post subject: |
|
|
| IvanYosifov wrote: | | Quote: |
Really, do you think that reiser4 is ready for a production system yet?
|
At least I , as stated a few pages ago, do not |
of course, no-one does think so. well, exept Linspire and Yoper
but hey, I have some first results for my stupid simple test - I wrote a script that tested 3 kernels compiling a small (I think too small, after all) program for ext3, reiser4 and reiserfs (3.6). the results for my first kernel, 2.6.11-cko3:
| Code: | copying the full portage tree (had to do that anyway, so benchmarked it...)
ext3: 3m18.12 100%
reiserfs: 2m41.63 -18.4%
reiser4: 2m15.01 -31.9%
compiling the program 'time':
ext3: 1m8.72 100%
reiserfs: 1m8.78 -0.00%
reiser4: 1m7.99 -0.01% |
looks like it does not really make a difference for compiling, altough I should try again with a bigger application (I'll do that tonight). |
|
| Back to top |
|
|
Enlight
Advocate
Joined: 28 Oct 2004
Posts: 3508
Location: Alsace (France)
|
| Posted: Tue Apr 19, 2005 9:31 am Post subject: |
|
|
| superstoned wrote: |
| Code: | copying the full portage tree (had to do that anyway, so benchmarked it...)
ext3: 3m18.12 100%
reiserfs: 2m41.63 -18.4%
reiser4: 2m15.01 -31.9%
|
looks like it does not really make a difference for compiling, altough I should try again with a bigger application (I'll do that tonight). |
wow, could you please tell us what kind of cpu & hard disk, is it possible that you test JFS and XFS too? |
|
| Back to top |
|
|
fallow
Bodhisattva
Joined: 08 Jan 2004
Posts: 2206
Location: Poland
|
| Posted: Tue Apr 19, 2005 10:09 am Post subject: |
|
|
hehe , once again : pure performance of fs isnt all hehe. no matter about cpu usage and interactivity at all ? If only clear performance is important for You , then also please do some more accurate tesing like this : | Code: |
001] Create 10,000 files with touch in a directory.
002] Run 'find' on that directory.
003] Remove the directory.
004] Create 10,000 directories with mkdir in a directory.
005] Run 'find' on that directory.
006] Remove the directory containing the 10,000 directories.
007] Copy kernel tarball from other disk to test disk.
008] Copy kernel tarball from test disk to other disk.
009] Untar kernel tarball on the same disk.
010] Tar kernel tarball on the same disk.
011] Remove kernel source tree.
012] Copy kernel tarball 10 times.
013] Create 1GB file from /dev/zero.
014] Copy the 1GB file on the same disk.
015] Split a 10MB file into 1000 byte pieces.
016] Split a 10MB file into 1024 byte pieces.
017] Split a 10MB file into 2048 byte pieces.
018] Split a 10MB file into 4096 byte pieces.
019] Split a 10MB file into 8192 byte pieces.
020] Copy kernel source tree on the same disk.
021] Cat a 1GB file to /dev/null. |
scripts here : http://wa.fema.pl/~gkowal/fsbench/
or If You prefer more real testing , then not only big pack of small files like portage , hm , or if You looking only for filesystem for portage
cheers.
_________________
"Time is a companion that goes with us on a journey. It reminds us to cherish each moment, because it will never come again. What we leave behind is not as important as how we have lived" J-L. Picard |
|
| Back to top |
|
|
Enlight
Advocate
Joined: 28 Oct 2004
Posts: 3508
Location: Alsace (France)
|
| Posted: Tue Apr 19, 2005 11:41 am Post subject: |
|
|
Well my goal would be to stick with only one file system cause reducing the size of my kernel gave me a real impression of my desktop running faster, I do care about interactivity, but I just considered that when I'm not emerging stuffs, my cpu is rarely under heavy load or for a really few time (switching beetween desktops or loading apps, that's almost all and when emerge writes or removes files, compilation is already over).
I'm not people with enough luck to expect reiser4 to work without any troubles on my machine, but there are some features in XFS that from what I heared may fasten the speed of the file system at the price of increasing cpu load.
fallow, that's 1/3 faster to copy the kernel tree and thats _huge_! |
|
| Back to top |
|
|
superstoned
Guru
Joined: 17 Dec 2004
Posts: 430
|
| Posted: Tue Apr 19, 2005 12:04 pm Post subject: |
|
|
| Enlight wrote: | Well my goal would be to stick with only one file system cause reducing the size of my kernel gave me a real impression of my desktop running faster, I do care about interactivity, but I just considered that when I'm not emerging stuffs, my cpu is rarely under heavy load or for a really few time (switching beetween desktops or loading apps, that's almost all and when emerge writes or removes files, compilation is already over).
I'm not people with enough luck to expect reiser4 to work without any troubles on my machine, but there are some features in XFS that from what I heared may fasten the speed of the file system at the price of increasing cpu load.
fallow, that's 1/3 faster to copy the kernel tree and thats _huge_! |
well, MY goal is to have several filesystems, each doing what it's good at. so I want to compare the real-world portage performance with several filesystems. well, I don't copy the portage tree very often, so I'm going to test tonight the performance of emerge --sync on each filesystem, and the performance of a bigger compile. And indeed, the performance increase of 30 % for reiser4 compared to ext3, for copying the portage tree, that's huge. So in THAT regard, reiser4 is faster. period. now I'll test rebuilding the portage db, compiling and sync'ing! |
|
| Back to top |
|
|
fallow
Bodhisattva
Joined: 08 Jan 2004
Posts: 2206
Location: Poland
|
| Posted: Tue Apr 19, 2005 2:39 pm Post subject: |
|
|
to be sincere . Wen Im doing copying of my portage dir ? . I neved did it. hmm maybe some times when Im doing a backup.
emerge sync isnt a copy of portage dir
and as I told , my /usr/src and portage is in reiser3 absolutely no reason for my to user reiser4 instead of reiser3. rest of the system.
my golas for choosing fs are : interactivity of the system in fs load situations and the second is performance , not first. stablility is very individual question for each one of us.
for me isnt very matter about copying of my dir will be done in 35 or 43 seconds. I want to have very good overall interactivity of my destkop in every situtation
cheers.
_________________
"Time is a companion that goes with us on a journey. It reminds us to cherish each moment, because it will never come again. What we leave behind is not as important as how we have lived" J-L. Picard |
|
| 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
|
|
Off the Wall
