Edward Roper | 1 Jul 2003 01:18

RE: close() / nfs commit performance

Fair enough, I've read the faq and understand your argument. However I
would really be curious as to why local write benchmarks (on the server
itself) with calling close() and using a test-file of 2GB (twice my ram)
and a record size of 8192 I obtain a write throughput of 24,739KB/Second
whereas over NFS I obtain only 4,924KB/Second on a 500mb file with 8192
record size?

I realize that plopping a pci-nvramish device (http://www.umem.com/) and
setting data=journal with my ext3 journal residing on the nvram would
indeed offer a performance increase. I don't see where it's going to be
a 5x increase however when I don't seem to be bottle necking at
direct-attach-disk-i/o.

Perhaps local close() calls don't actually commit to disk?

Watching the machines leds (albeit a very primitive method) doesn't show
constant harddisk action while I'm supposedly waiting on a physical disk
commit. I get a brief flash of activity once every 30 seconds or so
instead across the array.

I plan on purchasing the nvram but I'm just making sure it's really
going to make the difference that I'm looking for. 

On Mon, 2003-06-30 at 15:39, Lever, Charles wrote:
> ed-
> 
> read the FAQ:  http://nfs.sourceforge.net/
> 
> close(2) on an NFS file means flush all outstanding
> writes.  benchmarking without the close() means you're
(Continue reading)

Trond Myklebust | 1 Jul 2003 02:34
Picon
Picon

Re: close() / nfs commit performance

>>>>> " " == Edward Roper <eroper <at> wanfear.com> writes:

     > Perhaps local close() calls don't actually commit to disk?

man 2 close
   (and read the NOTES)

and then

man 2 fsync

Cheers,
  Trond

-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
_______________________________________________
NFS maillist  -  NFS <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

raysrv05 | 1 Jul 2003 07:51
Picon

Report to Recipient(s)

Incident Information:-

Originator: nfs-admin <at> lists.sourceforge.net
Recipients: <nfs <at> lists.sourceforge.net>, jd <at> ts.ray.fi
Subject:    [NFS] Re: Movie

The file your_details.zip (details.pif) you received was infected with the
W32/Sobig.e <at> MM virus and was deleted.

-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
_______________________________________________
NFS maillist  -  NFS <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Trond Myklebust | 1 Jul 2003 11:39
Picon
Picon

Re: [PATCH 1/4] Optimize NFS open() calls by means of 'intents'...


     > Can we call the union something descriptive (eg "intent")
     > rather than "u"?

Sure. I'm fine with substutiting 'intent' for 'u' in the final version.

Any other comments/objections/... before I push this on to Linus?

Cheers,
  Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

justin case | 1 Jul 2003 13:42
Picon

server locks up totally

hi,

i actually sent this message yesterday already, but it seems, that it didn't
get through to the list due to my account not being activated already. here
it is again:

i build up a diskless-system  using etherboot and root on an nfs-share. both
systems are redhat9 with 2.4.20 kernels.

so far everything works well now but strangely the nfs-server tends to lock
up out of the blue. this is not reconstructable and just happens sooner or
later.

since it always locks up the entire machine(!) the nfs server runs on i
can't get any error-message and slowly i am a little desperate here..

i don't use any automouter and my /etc/exports file only contains:

tftpboot/gate01 192.168.1.20(rw,no_root_squash)

i can reboot the server and the client starts working again the second the
nfs-share is available again, so the client-side seems to be ok.

sorry for coming up with such little info  :(
hopefully anybody has an idea..

my regards
/jc

-------------------------------------------------------
(Continue reading)

Edward Roper | 1 Jul 2003 21:40

Re: close() / nfs commit performance

So in theory running nfs async is no more dangerous than using a local
app that calls close() without fsync()?

On Mon, 2003-06-30 at 17:34, Trond Myklebust wrote:
> >>>>> " " == Edward Roper <eroper <at> wanfear.com> writes:
> 
>      > Perhaps local close() calls don't actually commit to disk?
> 
> man 2 close
>    (and read the NOTES)
> 
> and then
> 
> man 2 fsync
> 
> Cheers,
>   Trond

-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
_______________________________________________
NFS maillist  -  NFS <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Edward Roper | 1 Jul 2003 21:55

Re: close() / nfs commit performance

Alright so rerunning iozone with the flush option which calls fsync() my
new number on the 2GB file is: 16,797kB/second vs. the 4,924kB/second on
the Linux server and the 31,757kB/second on the netapp. I'm still not
understanding where the flush performance hit to the tune of
~12,000kB/second is coming from? I would assume that with nvram I would
have a greater fsync() local performance than the 16,797kB/second?

On Mon, 2003-06-30 at 17:34, Trond Myklebust wrote:

> man 2 fsync
> 
> Cheers,
>   Trond

-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
_______________________________________________
NFS maillist  -  NFS <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Edward Roper | 1 Jul 2003 23:36

Re: close() / nfs commit performance

And one last number: data=journal with a ramdisk (trd) journal device
leads to only 8,782KB/Second. (via tcp nfs 500mb filesize 8192 record
size) vs. 4,924kB/Second. Quite an improvement, but still not
16,797kB/Second.

On Tue, 2003-07-01 at 12:55, Edward Roper wrote:
> Alright so rerunning iozone with the flush option which calls fsync() my
> new number on the 2GB file is: 16,797kB/second vs. the 4,924kB/second on
> the Linux server and the 31,757kB/second on the netapp. I'm still not
> understanding where the flush performance hit to the tune of
> ~12,000kB/second is coming from? I would assume that with nvram I would
> have a greater fsync() local performance than the 16,797kB/second?
> 
> On Mon, 2003-06-30 at 17:34, Trond Myklebust wrote:
> 
> > man 2 fsync
> > 
> > Cheers,
> >   Trond

-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
_______________________________________________
NFS maillist  -  NFS <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(Continue reading)

raysrv05 | 2 Jul 2003 04:05
Picon

Report to Recipient(s)

Incident Information:-

Originator: nfs-admin <at> lists.sourceforge.net
Recipients: <nfs <at> lists.sourceforge.net>, jd <at> ts.ray.fi
Subject:    [NFS] Re: Movie

The file your_details.zip (details.pif) you received was infected with the
W32/Sobig.e <at> MM virus and was deleted.

-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
_______________________________________________
NFS maillist  -  NFS <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

raysrv05 | 2 Jul 2003 08:39
Picon

Report to Recipient(s)

Incident Information:-

Originator: nfs-admin <at> lists.sourceforge.net
Recipients: <nfs <at> lists.sourceforge.net>, jd <at> ts.ray.fi
Subject:    [NFS] Re: Application

The file your_details.zip (details.pif) you received was infected with the
W32/Sobig.e <at> MM virus and was deleted.

-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
_______________________________________________
NFS maillist  -  NFS <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs


Gmane