OESF Portables Forum
Everything Else => Zaurus Distro Support and Discussion => Distros, Development, and Model Specific Forums => Archived Forums => Sharp ROMs => Topic started by: derekp on February 09, 2004, 08:40:12 pm
-
I noticed an option in the .config file in Sharp\'s 2.4.18 kernel source, \"CONFIG_FS_SYNC = y\". It appears to force synchronous file i/o regardless of if you mount a filesystem with \"-o async\". This option appears to be an addition by Sharp along with the #ifdefs that test for it in various source files in the ./fs kernel source directory.
So, as a test, I tried un-taring a few files on an SD card (which was mounted -o async), with the standard kernel, and with a kernel compiled with this flag turned off. The results are that with CONFIG_FS_SYNC turned on (and SD card mounted -o async), the operation took 230 seconds, and running a kernel with it turned off, the test took only 19 seconds (average of several tries), more than a 10:1 speed increase.
Also, I tied it with someone elses SD card that was having problems under ext2, (a Sandisk card), and all the problems appeared to go away.
Can anyone else who\'s into compiling their own kernels try this out, and report back the results?
For the record, I\'m running with my /home on the SD card, and also lately have been dual-booting OpenZaurus from the SD card, and turning this compilation flag off has made a world of difference in speed.
Thanks,
--derek
-
I just uploaded my kernel which is compiled with this option turned off. I\'ve been running it for a month or so while running my system of the SD card, and it has made a big differnce in SD (and CF) write speeds. About a 10:1 speedup in some of the timing tests I\'ve done.
It is upload as file name \"zImage-sl5500-2.4.18-asyncio-c1\" under the 5500 kernel section.
-
This sounds great and since I\'m about to redo my Z I\'d like to try this, but I can\'t find it in the downloads section.
-
It should show up shortly, the admins of this site need to verify/approve all new uploads. Check back later tonight.
-
Thought so. Thanks. Guess I was a little too quick.
-
Awsome! I\'ve bult a kernel with this options turned off and I get huge speed increase accessing SD card! This will definitely be included in the next Cacko Qtopia ROM kernel!!
-
I\'m still waiting. =( Guess the speed excitment is getting the best of me.
-
Last time I uploaded something, it was available that evening. If it doesn\'t show up by this evening, then send me your email address, and I\'ll mail it to you (my email\'s dspsz@needcaffeine.net).
:edit: just found out I can attach a file directly to a comment
:edit 2: removed attachment from this comment, as the file has showed up in the download section now.
-
What are the negative aspects of removing CONFIG_FS_SYNC? I assume Sharp has it there for a reason. I would be interested in doing this for the next TKC if the corrupt SD card problems go away and there is no negative side affect. Anyone have something to say on this?
-
I believe the main effect would be that if you change out your CF/SD cards frequently, then you might accidently pull it out without unmounting/ejecting it first, which will result in potential data loss. However, if you use the \"-o sync\" mount option along with removing CONFIG_FS_SYNC, then it should have the same effect as leaving the flag turned on (not sure why Sharp didn\'t go this route in the first place). My vote would be to turn this flag off, and set the mount options for removeable media to default to -o sync (one could always issue a \"remount -o async\" on the device to change it on the fly). My prep-home-sd.sh script ends up mounting the SD card -o async anyways. (BTW, be sure to have proto grab the latest one, I uploaded it to this board as \"prep-home-sd_test5.zip\").
Unfortunately, Sharp didn\'t feel the need to add any comments to the code for this option. But the only parts that this option touches is in fs/buffer.c, fs/namei.c and fs/open.c (look for the \"#ifdef CONFIG_FS_SYNC\" lines in these files). I also did a google search on CONFIG_FS_SYNC, and the only thing that I came up with were a couple of pages that had someones .config file in them, and a japanese page that looked like someones journal. Babelfish did a weird job on that page.
-
Thanks...I will look into building that into the TKC 3.0 kernel. I will have a look at the code that references CONFIG_FS_SYNC and look at its implications before removing it. I am concerned that removing it may have a bigger impact than we think. Sharp clearly had it there for a reason and I want to verify its intentions.
-
I\'d be interested to see what you find out. For the record, I\'ve been running root off my SD card for a while with this and no ill effects. However, this of course doesn\'t involve frequent card swaps, which is where any implications may show up. But my CF card hasn\'t showed any filesystem problems yet.
-
Derekp, can you try posting this again as nothing has shown up yet? Thanks.
-
Thanks...I will look into building that into the TKC 3.0 kernel.
asshole TKC still alive? hehe...
-
asshole TKC still alive? hehe...
Hmmm...comment shows your IQ. And I did what to offend you?
-
asshole TKC still alive? hehe...
Oh yes...if you choose to throw stones, why hide behing the vail of anonymity. Cowardice is a poor quality.
-
Thanks derekp. I finally registered so I don\'t get caught up in this guest nonsense.
-
it\'s me
--sashz
-
Ahh sash...yeah I figured it was you...not too many childish folks running around on these forums.
Dude...I have no idea what your beef is with TKC or Proto or whatever...but I personally \"had\" no issues with you. In fact I was helping your team with wireless issues (talk to Laze). My kernel had nothing to do with you or your work, or your childish issues you had with proto, etc. So for you to call me an \"asshole\" is not only uncalled for, but also shows your true intelligence level. Personally sash, I would stop picking fights with people who did nothing to you (me) and take your energies and focus them elsewhere. In otherwords, you probably should grow up.
-
please... not again.
ok?
-
please.
-
I\'ve noticed that the kernel I uploaded finally showed up in the downloads section, so I went ahead and removed the attachment from my earlier post. Actually, it\'s there twice, since I re-uploaded it after a few days thinking that there was a problem with the original upload. One\'s just the kernel itself, the other one is in a zip file, but otherwise they\'re the same thing.
How shoud I bring it to the site admin\'s attention to remove the redundant one? Should I send a private message to offroadgeek?
Another note, this kernel is also compiled with support for ext3 filesystem. If you do a \"tune2fs -j /dev/mmcda1\" then it will turn journaling on. This might be desirable, seeing as how you\'d otherwise have a higher chance of filesystem corruption with async writes (i.e., if you pull out the SD card without ejecting it). For the record, I don\'t notice any performance penalty with the journaling.
-
Derek, are you sure about this command \"tune2fs -j /dev/mmcda1\". tune2fs doesn\'t know what the -j flag is on my unit. I\'m using your zImage file and the TKC ROM2alpha3 BIN file.
-
Another note, this kernel is also compiled with support for ext3 filesystem. If you do a \"tune2fs -j /dev/mmcda1\" then it will turn journaling on. This might be desirable, seeing as how you\'d otherwise have a higher chance of filesystem corruption with async writes (i.e., if you pull out the SD card without ejecting it). For the record, I don\'t notice any performance penalty with the journaling.
That\'s an interesting idea. What abotu space? How much do you think is the overhead?
BTW, I\'ve tried running some benchmarks without shsync process. The transfer rate is even higher - up to 1.5 Mb/sec, but then it\'s a pain if you need to eject a card. It would take a few seconds to flash the buffers. So I ended up with leaving shsync alone...
-
agosine, you might need to grab a different version of tune2fs. I\'m run openzaurus from my SD card, which has the -j (journal) flag, but if I remember right, the version on the sharp rom doesn\'t have it.
Back a while ago, I compiled a bunch of standard linux utilities for the Z, I think a copy of tune2fs was one of them. I\'ll do some digging and mail it to you if I find it.
-
Another note, this kernel is also compiled with support for ext3 filesystem. If you do a \"tune2fs -j /dev/mmcda1\" then it will turn journaling on. This might be desirable, seeing as how you\'d otherwise have a higher chance of filesystem corruption with async writes (i.e., if you pull out the SD card without ejecting it). For the record, I don\'t notice any performance penalty with the journaling.
That\'s an interesting idea. What abotu space? How much do you think is the overhead?
BTW, I\'ve tried running some benchmarks without shsync process. The transfer rate is even higher - up to 1.5 Mb/sec, but then it\'s a pain if you need to eject a card. It would take a few seconds to flash the buffers. So I ended up with leaving shsync alone...
The smallest size journal you can have is 1 block, which should be 1K using the default block size. Not sure what the default size is.
Also, as you are probably aware, when doing async io on flash media, any increase in raw transfer rate is artificial, that is once you include the time to sync the filesystem you end up with about the same speed as with sync writes (you have to \"pay the piper eventually\", so to speak). And given enough data, you eventually run out of ram so you\'d have to wait for the data to write out at that point. On a drive that has physical head movement, there are significant real speedups, as data can be written in a more efficient order. On the other hand, async i/o also filters out redundant writes. So in the case of writing out a bunch of smaller files where it has to update the same disk blocks (inode table) multiple times, you get a real speed up.
As far as speed differences between running with v.s. without a journal, I haven\'t done any formal benchmarking, but untaring something with sync i/o takes about a second to write out each file, whereas with async an untar command flies by. And it still flies by with about the same speed with journaling on.
-
Thanks for the info. I may try to build myself a kernel with ext3 support. The only pronlem is that when preparing the new ROM I\'ve been flashing ROMs back and forth like crazy, so I\'m tired of that and want to settle down a bit
-
I hope the next pdaxrom has this option.
Scott
-
Derekp I have tested this and posted my results here :-
http://www.zaurususergroup.com/index.php?n...iewtopic&t=2292 (https://www.oesf.org/forums/index.php?showtopic=2292)
Many thanks for discovering this, it really works.
Peter.
-
I hope that X11 and Qtopia ROMs will have compatible, if not the same kernels. Ill work with sash on that.
-
thank you