| Marc de Vries 2004-07-20, 5:45 pm |
| On Mon, 19 Jul 2004 16:07:23 +0200, "Folkert Rienstra"
<see_reply-to@myweb.nl> wrote:
>
>"Marc de Vries" <marcdevries@geen.spam.zonnet.nl> wrote in message news:qi7nf0piehsg6g4nebgdp15encc38ng9s6@
4ax.com
>
>Nope, only on busy servers that do alot of them simultaniously.
If the server is doing nothing he wouldn't have a bought a Smart array
5300 controller for it.
>
>Therefor still reads at full stripe width transfer rates.
Which is not important for those very small files at all.
>
>Not if this is not a "busy" server. The bigger the stripe size the more
>small files that sit on a single disk and transfer at single disk speeds.
>If that's not compensated by the shear number of them that a part of
>is read simultaniously all the time then you loose.
Wrong. As I have explained you time and again in the past the
transfer rate is not important for small files. Why don't you listen!
When you read thousands of files of 350 bytes size it doesn't matter
if I read them with 30MB/s transfer rate or which 300MB/s transfer
rate. The time to get the file depends solely on the time that is
needed to seek and open the file. That takes 90% of the total time to
get the file. Since the transferrate only takes 10% of the time the
impact of a faster transferrate is neglictable. (rough estimates, it
will be even less for 350 bytes files, but you will remember these
numbers from a few days ago when I explained it to you in detail)
>
>So you actually make them slower, to read more of them simultaniously.
Almost right.
I actually make the transferring of the small files slower by 0.00001%
because of a lower transferrate and then make the transfer of the
total set of files faster by 400% because I can open multiple files at
once.
>On a not so busy server you are insuring that the small files will transfer
>even slower compared to doing nothing. Nice one.
On a server that is only opening 1 file at a time. (not a realistic
scnenario) I am slowing down the opening of that file by 0.00001%
So who cares about that? (well you do obviously, but anyone actually
using that server in real life server won't)
>When you leave it as it is that you thought was best, at least you don't
>make the ones that fill a stripe width slower, and, when they are less
>than that, smaller files automatically fill up the gap when the server is
>busy and has many outstanding IO.
>
>
>Right, now for yourself to let that sink in.
How about you actually start to listen to what I explain to you and
LEARN from it?
>
>Not on a busy server, no. And not if the write speed is not disk related.
>It will if it is and the cache can catch up in less busier periods acting
>as a buffer.
>
>
>What "it"?
>
>
>
>Actually it does when already small files fragment because of it.
How about you start reading the thread again.
We are talking about files that are about 350 bytes in size!
The smallest cluster size that NTFS supports is already much bigger
then that: 512 bytes. So how are these files going to be fragmented by
that clustersize?
>
>Unless they sit on a dedicated drive that is not mechanical in nature.
>Solid State Disk.
That could be an option. But Even though there are lots of very small
files in the roaming profile, the rest of the roaming profile could be
very big. Windows probably won't let the profile be stored on two
different types of disk.
>
>That obviously depends on the type of backup.
Obviously that is also the reason why I said that the backup is
PROBABLY not too happy about it.
For some backup methods it indeed doesn't matter.
Marc
|