Re: lseek/write

On Nov 19, 2:33 pm, David Schwartz <dav...@xxxxxxxxxxxxx> wrote:
On Nov 18, 5:19 pm, golden <i...@xxxxxxxxxxxxx> wrote:

I have a question regarding disk IO performance. I would like to
understand why exactly writes to a disk are faster when I use lseek as
opposed to not using lseek. The snippet of code that I am using is as
follows:

Your test does two very different things. If 'lseek' is called, it
keeps overwriting the same piece of information. If 'lseek' is not
called, it keeps writing new information each time. It slows down when
you remove the 'lseek' because with the 'lseek' the writes cannot fit
in cache and with it, they can.

Ahhh... so without the write buffer, i continuously add to my buffer
cache. When I call fsync i flush the cache to disk but only the new
data is actually written to disk?


I would imagine that the write keeps track of the pointer after each
write, but my test does not bear that out.

Actually, your test bears that out. Why do you think not?

Ultimately, I am trying to determine why writes are faster to my local
disk than to my SAN storage (EMC w/ cache).

There's really no reason they should be, depending on how your SAN is
set up.

When I use the fsync,
writes are slower to san.

Well, duh. Synching is slow.

When I do not use the fsync, writes are
faster.

Right. Not synching is faster than synching.

I would appreciate any information regarding t his topic.

What do you find surprising exactly?

What I am trying to determine is why my writes are faster to my local
disk than to my SAN ( all things being equal) . If I remove the
fsync, my write is faster to the SAN. I assume that the OS handles
the writes far more effeciently in this case. When I fsync after each
write i remove any performance enhancements the OS can provide. So
The only conclusion I can come up with is that there are more hops to
the SAN. The transfer from memory to local disk cache is faster than
the fiberchannel path.

Thanks,

DS

.

Relevant Pages

  • Re: Separate Data and Log files
    ... It is quite possible that a SAN can mask the need to separate the files due ... How much relevance is this> documentation with newer SAN technologies where there are large buffer> caches. ... > that the data is written to disk when in actuality it is still in cache> waiting to be written to disk. ...
    (microsoft.public.sqlserver.setup)
  • Re: Exchange 2007 SCC Cluster - Slow Failover
    ... Doesn't surprise me a bit. ... A SAN is not a panacea for performance issues, ... the SAN and the disk layout? ... cache to a copy of the database that won't be used". ...
    (microsoft.public.exchange.admin)
  • Re: lseek/write
    ... lseek as opposed to not using lseek. ... Because seeking back to zero all the time means the writes get ... written over before being flushed to disk. ... EMC's cache isn't going to speed up getting the data from ...
    (comp.os.linux.development.system)
  • Re: Separate Data and Log files
    ... Most of the modern SAN vendors (EMC, Hitachi, ... > data cache hit and cpu utilization of aroun 40%. ... > Does Microsoft have anything documented or maybe even some SAN vendor? ... >>> pertaining to physical disk layouts. ...
    (microsoft.public.sqlserver.setup)
  • Re: How accurate are AIX disk reporting metrics with a SAN?
    ... mean anything on a SAN? ... Its looks like your focusing on the data distribution on the disk. ... answered only by you since i do not know your SAN configuration, ... configure the cache on the SAN to your needs. ...
    (comp.unix.aix)