Re: what do you do that stresses your filesystem?
Ookhoi wrote: Hans Reiser wrote (ao): I mostly meant waiting for the fs to read all the binaries that get executed at startup, not just the journal replay time. So you run redhat eh ;-) Can you please make a reiserfs4 snapshot available for testing before you all enjoy a nice Christmas? I pushed a little more on this... you'll get something before western Xmas.
Re: what do you do that stresses your filesystem?
Oleg Drokin wrote (ao): > On Tue, Dec 24, 2002 at 11:15:27AM +0100, Ookhoi wrote: > > Can you please make a reiserfs4 snapshot available for testing > > before you all enjoy a nice Christmas? > > Russian (hm, should I say Greek Orthodox here?) Christmas is after New > Year, anyway ;) Owh, I'm sorry :-] Guess I need to read up on that one. > We will release new snapshot before New Year, I think. Great, thanks!
Re: what do you do that stresses your filesystem?
Hello! On Tue, Dec 24, 2002 at 11:15:27AM +0100, Ookhoi wrote: > Can you please make a reiserfs4 snapshot available for testing before > you all enjoy a nice Christmas? Russian (hm, should I say Greek Orthodox here?) Christmas is after New Year, anyway ;) We will release new snapshot before New Year, I think. Bye, Oleg
Re: what do you do that stresses your filesystem?
Hans Reiser wrote (ao): > I mostly meant waiting for the fs to read all the binaries that get > executed at startup, not just the journal replay time. So you run redhat eh ;-) Can you please make a reiserfs4 snapshot available for testing before you all enjoy a nice Christmas?
Re: what do you do that stresses your filesystem?
Chris Haynes, maybe as we bring atomic transactions into use we should work with you to see if they address your needs. Chris Mason, maybe you might want to comment on what he is doing with threads and how it interacts with V3 journal commits? (I bet you are on vacation though?) Hans Chris Haynes wrote: Hans, Thanks for asking! I'm about to deploy an on-line transaction-based service.. All service-specific software is in 1000+ Java classes. The OS is SuSE 7.3, and Java version 1.4 The heavist uses of the file store are: During development: + javadoc During service deployment / update: + rsync + When using a tripwire-like Java program which checks the SHA digest of all deployable files against zipped JARs During production operation: + atomic, synchronized writes to multiple files (typically 3 - 4 files in different directories, the first is the creation of a new 4 kb file, others are usually updates of existing files - growing typically 1kb per update). This files system is mounted on a RAID-1 pair. + rsync + Successive reading of all files in a directory sub-tree (up to 10M files) in filestore-defined order (i.e. the program makes no demands or assumptions about the order - it uses the order supplied by Java's File.files()). The greatest performance concern I have is with the file writes. As these are atomic transactions, I use a separate thread for each file's write (to give the kernel's escalator a chance to work), and require that the write operations be individually hardware-synchronized using Java's FileDescriptor.sync() method. I then use a counter to detect when all threads have reported that their files have been written - this indicating successful commitment of the transaction. I handle read-and write-locking in the application. Usually, there are no lock conflicts, so there can be many concurrent transaction commitments. I use a thread pool of 50 threads to handle the individual file writes (the 50 being a guess at the likely point of diminishing returns). My expectation/hope is that, so long as there are enough threads available in this pool, all transactions will be completed within one disk rotation period(regardless of the number of concurrent transactions or number of files per transaction and the fact that I'm using software RAID-1). I've not yet been able to validate this (theoretically or practically). I would *really* like to be able to group all the file writes for a transaction into a single logical API call and have the kernel/file system report successful completion of all data and metadata aspects of the transaction using a single application thread. HTH Chris Haynes
Re: what do you do that stresses your filesystem?
Russell Coker wrote: On Mon, 23 Dec 2002 12:28, Hans Reiser wrote: We were discussing how to optimize reiser4 best, and came to realize that us developers did not have a good enough intuition for what users do that stresses their filesystem enough that they care about its performance. Booting the machine seems like one activity that many users end up waiting on the FS for. Yes? Yes, although there are other factors than the file system which determine boot time. Different types of init scripts can probably improve performance more than anything you could do to a file system. Also if you have a rack-mount server then it'll probably take 2 minutes or more to go through the BIOS checks so FS delays will seem like nothing by comparison. I mostly meant waiting for the fs to read all the binaries that get executed at startup, not just the journal replay time.
Re: what do you do that stresses your filesystem?
Ed Tomlinson wrote: On December 23, 2002 06:45 am, Hans Reiser wrote: Anders Widman wrote: Booting the machine seems like one activity that many users end up waiting on the FS for. Yes? Hopefully we do not have to reboot to often... :) buying the seagate hard drives with fluid ballbearings (and fanless heatsinks) reduces the need to halt at bedtime by a lot. Various (pulls, clones) bk operations using the 2.5 kernel tree. Ed Tomlinson Isn't that CPU and memory bound?
Re: what do you do that stresses your filesystem?
Am Montag, 23. Dezember 2002 12:37 schrieb Anders Widman: > > We were discussing how to optimize reiser4 best, and came to realize > > that us developers did not have a good enough intuition for what users > > do that stresses their filesystem enough that they care about its > > performance. > > > > If you just do edits of files it probably does not matter too much what > > fs you use. > > depends on how large edits =).. Like video-editing requires big > r/w performance. Like Andrew Morten suggest all the time (deadline IO tests): Running (heavy) constant (streaming) IO in the background during "normal" IO (20-40 parallel gcc/g++ compilers (make -j20) in my case). WMs e.g. KDE 3.1 isn't a case any longer...;-) Give your "workers" a break. Merry Christmas! -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science @home: Dieter.Nuetzel at hamburg.de (replace at with @)
Re: what do you do that stresses your filesystem?
On Mon, Dec 23, 2002 at 02:28:32PM +0300, Hans Reiser wrote: > We were discussing how to optimize reiser4 best, and came to realize > that us developers did not have a good enough intuition for what users > do that stresses their filesystem enough that they care about its > performance. Something else you might want to do is measure "commit latency"... the time between file operations being made by userland, and those operations becoming durable (i.e. getting committed into the log). If you can benchmark this, it might give users more confidence. (When I clicked save, it did, actually, save!) This is kind of related to real-time stuff, which is another thing you might want to test. Eg: audio/video playback... can reiserfs sustain IO bandwidth well, without falling behind occasionally? (i.e. maintaining low latency) XFS has (had? I think it's only the irix port) an ioctl to tell the OS "I want to read 300kb/s with maximum 0.1ms latency on fd 3". (The ioctl() would fail if Irix couldn't guarantee that) I'm not saying this is useful for everyone, just it should help you understand the performance better... Cheers, Andrew
Re: what do you do that stresses your filesystem?
On 12/23/2002 12:28 PM, Hans Reiser wrote: We were discussing how to optimize reiser4 best, and came to realize that us developers did not have a good enough intuition for what users do that stresses their filesystem enough that they care about its performance. If you just do edits of files it probably does not matter too much what fs you use. Booting the machine seems like one activity that many users end up waiting on the FS for. Yes? Starting up complex and big applications like xemacs and mozilla would be another. Yes? Others? Anyone already mentioned VMware sessions? ;-) Running VMware on a Linux host would be an example. The application itself is no problem for the fs. But maybe the case when the VMware's guest OS is under high memory usage and disk i/o and VMware swaps out to a file in /tmp on the host OS. Usually this happens at the same time when Linux swaps out the "unneeded" things, on here: parts of KDE and Netscape7+. So it is no fs only stress test at all. I can suggest running SpeedDisk on your fragmented Win98 disks from within VMware to have this scenario. (Then, switching to a mail composer window under Linux and waiting for the cursor ... takes ... some time...) Regards, Manuel Hans PS reiser4 performance is up a lot recently, and within two weeks I think cp -r will have been optimized as much as is worth doing. cp -r accesses files in readdir order, and that does indeed seem worth optimizing, but soon we will need to optimize more sophisticated access patterns than that. Hans
Re: what do you do that stresses your filesystem?
On Mon, 23 Dec 2002 16:56, Ross Vandegrift wrote: > On machines with Linux md RAID arrays that need to be remirrored, > I do end up waiting a bit (10-30 seconds) due to read starvation, but > this problem is so much better than it used to be it's hardly worth > mentioning. One thing I've done before is configure the boot scripts to set the RAID re-sync speed very low before fsck/mount time and then set it back later. It didn't seem to do as much good as I thought it would though. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: what do you do that stresses your filesystem?
Some others I can think of... Running Wine and winex applications Running games, such as ut2003. I don't mean card games. Running game servers too... Starting large Window managers like KDE. Mat On Monday 23 December 2002 03:28 am, Hans Reiser wrote: > We were discussing how to optimize reiser4 best, and came to realize > that us developers did not have a good enough intuition for what users > do that stresses their filesystem enough that they care about its > performance. > > If you just do edits of files it probably does not matter too much what > fs you use. > > Booting the machine seems like one activity that many users end up > waiting on the FS for. Yes? > > Starting up complex and big applications like xemacs and mozilla would > be another. Yes? > > Others? > > Hans > > PS > > reiser4 performance is up a lot recently, and within two weeks I think > cp -r will have been optimized as much as is worth doing. cp -r > accesses files in readdir order, and that does indeed seem worth > optimizing, but soon we will need to optimize more sophisticated access > patterns than that. > > Hans
Re: what do you do that stresses your filesystem?
Hans, Thanks for asking! I'm about to deploy an on-line transaction-based service.. All service-specific software is in 1000+ Java classes. The OS is SuSE 7.3, and Java version 1.4 The heavist uses of the file store are: During development: + javadoc During service deployment / update: + rsync + When using a tripwire-like Java program which checks the SHA digest of all deployable files against zipped JARs During production operation: + atomic, synchronized writes to multiple files (typically 3 - 4 files in different directories, the first is the creation of a new 4 kb file, others are usually updates of existing files - growing typically 1kb per update). This files system is mounted on a RAID-1 pair. + rsync + Successive reading of all files in a directory sub-tree (up to 10M files) in filestore-defined order (i.e. the program makes no demands or assumptions about the order - it uses the order supplied by Java's File.files()). The greatest performance concern I have is with the file writes. As these are atomic transactions, I use a separate thread for each file's write (to give the kernel's escalator a chance to work), and require that the write operations be individually hardware-synchronized using Java's FileDescriptor.sync() method. I then use a counter to detect when all threads have reported that their files have been written - this indicating successful commitment of the transaction. I handle read-and write-locking in the application. Usually, there are no lock conflicts, so there can be many concurrent transaction commitments. I use a thread pool of 50 threads to handle the individual file writes (the 50 being a guess at the likely point of diminishing returns). My expectation/hope is that, so long as there are enough threads available in this pool, all transactions will be completed within one disk rotation period(regardless of the number of concurrent transactions or number of files per transaction and the fact that I'm using software RAID-1). I've not yet been able to validate this (theoretically or practically). I would *really* like to be able to group all the file writes for a transaction into a single logical API call and have the kernel/file system report successful completion of all data and metadata aspects of the transaction using a single application thread. HTH Chris Haynes
Re: what do you do that stresses your filesystem?
Russell Coker wrote on Mon, 23 Dec 2002 14:21:52 +0100: > Mail serving with Maildir storage. Same sort of thing here. Thousands of e-mail and news files in a directory, so displaying them in a GUI directory display window can be slow. Particularly if it is also getting attributes to display (from, to, subject, date, thread). This is under BeOS/BFS and can get a bit slow if the attributes end up in disk sectors far away from the inode for the file (but speed is good when block size (== inode size) is boosted up enough so that the attributes all fit in the inode). So, directory reading speed plus attribute reading speed are important to me. - Alex
Re: what do you do that stresses your filesystem?
On Mon, Dec 23, 2002 at 02:28:32PM +0300, Hans Reiser wrote: > Booting the machine seems like one activity that many users end up > waiting on the FS for. Yes? Not really. I've been running ReiserFS for at least three or four years. I haven't seen a machine have to fsck in forever ::-) On machines with Linux md RAID arrays that need to be remirrored, I do end up waiting a bit (10-30 seconds) due to read starvation, but this problem is so much better than it used to be it's hardly worth mentioning. > Starting up complex and big applications like xemacs and mozilla would > be another. Yes? Not really - I've found that apps like mozilla are usually loaded from disk exactly once per reboot, and then stay cached in memory until the box is restarted. Most of the startup time comes from the app doing lots of work itself - subsequent starts show no disk activity at all. > Others? As a long time user of ReiserFS, I don't really wait on the filesystem anymore. With Ext2, I used to wait on large deletes, but that's clearly not an issue anymore. I've noticed that when I need a performance upgrade, a faster disk is the best solution. -- Ross Vandegrift [EMAIL PROTECTED] A Pope has a Water Cannon. It is a Water Cannon. He fires Holy-Water from it.It is a Holy-Water Cannon. He Blesses it. It is a Holy Holy-Water Cannon. He Blesses the Hell out of it. It is a Wholly Holy Holy-Water Cannon. He has it pierced.It is a Holey Wholly Holy Holy-Water Cannon. He makes it official. It is a Canon Holey Wholly Holy Holy-Water Cannon. Batman and Robin arrive. He shoots them.
