Spencer Shepler <[EMAIL PROTECTED]> wrote:
> I didn't comment on the error conditions that can occur during
> the writing of data upon close(). What you describe is the preferred
> method of obtaining any errors that occur during the writing of data.
> This occurs because the NFS client is writing asynchronously and the
> only method the application has of retrieving the error information
> is from the fsync() or close() call. At close(), it is to late
> to recovery so fsync() can be used to obtain any asynchronous error
> state.
>
> This doesn't change the fact that upon close() the NFS client will
> write data back to the server. This is done to meet the
> close-to-open semantics of NFS.
Your working did not match with the reality, this is why I did write this.
You did write that upon close() the client will first do something similar to
fsync on that file. The problem is that this is done asynchronously and the
close() return value does noo contain an indication on whether the fsync
did succeed.
> > It would also make it harder to implement error control as it may be that
> > a problem is detected late while another large file is being extracted.
> > Star could not just quit with an error message but would need to delay the
> > error caused exit.
>
> Sure, I can see that it would be difficult. My point is that tar is
> not only waiting upon the fsync()/close() but also on file and directory
> creation. There is a longer delay not only because of the network
> latency but also the latency to writing the filesystem data to
> stable storage. Parallel requests will tend to overcome the delay/bandwidth
> issues. Not easy but can be an advantage with respect to performance.
I see no simple way to let tar implement concurrenty with respect to these
problems. In star, it would be possible to create detached threads that
work independently on small files that in sum are smaller than the size of the
FIFO. This would however make the code much more complex.
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
