Spencer Shepler <[EMAIL PROTECTED]> wrote:
> The close-to-open behavior of NFS clients is what ensures that the
> file data is on stable storage when close() returns.
In the 1980s this was definitely not the case. When did this change?
> The meta-data requirements of NFS is what ensures that file creation,
> removal, renames, etc. are on stable storage when the server
> sends a response.
>
> So, unless the NFS server is behaving badly, the NFS client has
> a synchronous behavior and for some that means more "safe" but
> usually means that it is also slower that local access.
In any case, calling fsync before close does nto seem to be a problem.
> > You tell me ? We have 2 issues
> >
> > can we make 'tar x' over direct attach, safe (fsync)
> > and posix compliant while staying close to current
> > performance characteristics ? In other words do we
> > have the posix leeway to extract files in parallel ?
> >
> > For NFS, can we make 'tar x' fast and reliable while
> > keeping a principle of least surprise for users on
> > this non-posix FS.
>
> Having tar create/write/close files concurrently would be a
> big win over NFS mounts on almost any system.
Do you have an idea on how to do this?
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED] (uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
