Basically, ALL filesystems which reside on disk are slow, and all filesystems which reside on random-access memory (even non-volatile NVRAM such as USB sticks) are fast.

Well obviously if my hard-disk was slow enough to get what I wanted, I wouldn't need to ask the question. So yes, I do have to write a simulator and was looking whether someone has already implemented that. That's called code reuse.

This is starting to sound like you're using the list to do your try to get your college-level programming projects done.

If you are so sure of yourself, you might want to check the email address, and then try the corresponding web site. You would find that's a commercial company doing open-source software. Hardly college-level. Beside, and that you couldn't guess, I graduated about 11 years ago, so that's a long time since I did assignments. When you don't have information, you do not have to absolutely try and answer. Other people might have more useful information, which you might eventually learn from as well. I guess I could quote a URL for the netiquette as well (don't be aggressive), but you might not read it. Emmanuel -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Emmanuel Briot wrote:

...

Basically, ALL filesystems which reside on disk are slow, and all filesystems which reside on random-access memory (even non-volatile NVRAM such as USB sticks) are fast.

Well obviously if my hard-disk was slow enough to get what I wanted, I wouldn't need to ask the question.

You're obviously missing the point of what I wrote. What makes disk filesystems slow is not the code run on the CPU...it's the operating speed of the disk-head actuator. It's not the filesystem that's slow, it's the DISK DRIVES that are slow. The disk I/O bottleneck is not the CPU overhead , it's the speed which the read/write head can be placed into the proper track position plus additional waiting for the correct sector to come around underneath the read/write head. There are not "slow" filesystems, only slow hard disks. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Emmanuel Briot wrote:

Now, Dave's proposal of using NFS is indeed what I have been doing so far, but nowadays local network become so fast that the difference is not that big.

As somebody else said, you can tell a NIC to run at say 10 Mbps.

I'll investigate the "rsize=1, wsize=1" parameters, which I do not know about.

Another thing that will slow NFS down is to restrict the number of daemons on the server. I can't remember exactly how to do it. Run a benchmark program at the same time to load the system :) Cheers, Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2007-11-15 at 09:49 +0100, Emmanuel Briot wrote:

Now, Dave's proposal of using NFS is indeed what I have been doing so far, but nowadays local network become so fast that the difference is not that big. All I want here is to be able to slow down the application while monitoring it in a profiler, which would help find out what parts of the application are slow.

Put the network on a serial port: you can choose from 1200 b/s up to 112e3 b/s. That's surely slow enough! :-) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFHPFV9tTMYHG2NR9URAjkrAJ9ZPcAUhGIS6tUMfTytdVUPbyrH0gCeKCg0 1k5aDMxNsXan+J51XnWDo+0= =O2oF -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Emmanuel Briot wrote:

...

What makes disk filesystems slow is not the code run on the CPU...it's the operating speed of the disk-head actuator.

It's not the filesystem that's slow, it's the DISK DRIVES that are slow.

The disk I/O bottleneck is not the CPU overhead , it's the speed which the read/write head can be placed into the proper track position plus additional waiting for the correct sector to come around underneath the read/write head.

There are not "slow" filesystems, only slow hard disks.

You have never used Windows, I guess. Its file system is much slower than any of those on linux, using the same disk (dual-booting).

I'm all too familiar with Windows. What makes it the MS filesystems slow is, again, disk head movement. MS filesystems have very inefficient disk-head movement patterns.

Now, if you can answer the question on what tools exist to simulate a slow hard-disk if you wish, that would be extremely interesting. That would be, I guess, a user-side file system that introduces explicit delays.

Now, Dave's proposal of using NFS is indeed what I have been doing so far, but nowadays local network become so fast that the difference is not that big. All I want here is to be able to slow down the application while monitoring it in a profiler, which would help find out what parts of the application are slow.

I'll investigate the "rsize=1, wsize=1" parameters, which I do not know about.

Personally, I think you'll get a "slow" filesystem, but that your data is not going to correlate very well with whatever you're modelling. If you want to test a "slow" filesystem, then just create and mount that type of filesystem, and do some I/O on it. Anything else is just mental masturbation (and if the date is going to be used for marketing purposes...fraudulent).

Emmanuel

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Anders Johansson wrote:

On Wednesday 14 November 2007 22:24:19 Aaron Kulkis wrote:

...

What makes disk filesystems slow is not the code run on the CPU...it's the operating speed of the disk-head actuator.

It's not the filesystem that's slow, it's the DISK DRIVES that are slow.

So what is your theory on why file system benchmarks produce widely different results? If what you say is true, and the only bottleneck is the drive, then they should all perform the same, right?

Some file systems are faster than others, and the difference can be staggering.

Disk layouts, mostly. How much disk head movement is need to complete an I/O transaction to the point that write(2) returns and the program resumes. Journaling is one of the big breakthroughs here -- all of the writes are put in a sequential strip of blocks on the disk drive...both the file contents AND the metadata are in contiguous blocks in the journal...even though in the actual file being written to, the meta data is usually in a block many many tracks away from where the contents of the file is located. The modification to the ACTUAL filesystem structure is delayed. Once all the write()s are completed, the filesystem driver (JFS or XFS or what have you) then starts processing the journal as the system permits... writing to the journal is a higher priority operation than processing the journal (unless the journal is full). It's all about disk-head movement. Disk DRIVES are slowwwwwwwwwww. Do a performance test using solid state devices instead of disk drives, and the differences between filesystems are negligible...and the filesystems which are fastest on hard disk drives (JFS, xfs, etc) due to the use of journaling are the SLOWEST on solid-state storage. Why? Because the disk-head movement performance penalty does not exist when there's no disk head. And the journaling trick to avoid it becomes a liability, because the write-journal/read-journal/write-filesystem methodology now just sucks up bandwidth, rather than eliminating disk-head movement during high volume file-writing activity. This is all fairly obvious, and doesn't even take inspection of the code to figure out.

Anders

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org