Roch <[EMAIL PROTECTED]> wrote:
> I would add that this is not a bug or deficientcy in
> implementation. Any NFS implementation tweak to make 'tar x'
> go as fast as direct attached will lead to silent data
> corruption (tar x succeeds but the files don't checksum
> ok).
>
> Interestingly the quality of service of 'tar x' is higher
> over NFS than direct attach since, with direct attach,
> there is no guarantee that files are set to storage whereas
> there is one with NFS.
Why do you beieve this?
Neither Sun tar nor GNU tar call fsync which is the only way to
enforce data integrity over NFS.
If you like to test this, use star. Star by default calls
fsync before it closes a written file in x mode. To switch this
off, use star -no-fsync.
> Net Net, for single threaded 'tar x', data integrity
> consideration forces NFS to provide a high quality slow
> service. For direct attach, we don't have those data
> integrity issues, and the community has managed to get by the
> lower quality higher speed service.
What dou you have in mind?
A tar that calls fsync in detached threads?
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
