Roch <[EMAIL PROTECTED]> wrote:
> > Neither Sun tar nor GNU tar call fsync which is the only way to
> > enforce data integrity over NFS.
>
> I tend to agree with this although I'd say that in practice,
> from performance perspective, calling fsync should be more
> relevant for direct attach. For NFS, doesn't close-to-open
> and other aspect of the protocol need to enforce much more
> synchronous operations ? For tar x over nfs I'd bet the
> fsync will be an over-the-wire ops (say 0.5ms) but will not
> add an additional I/O latency (5ms) on each file extract.
I did never test the performance aspects over NFS, as from my
experience this is the only way to grant detection of file write
problems.
> My target for a single threaded 'tar x' of small files is to
> be able to run over NFS at 1 file per I/O latency, no matter
> what the backend FS is. I guess that 'star -yes-fsync' over
> direct attach should behave the same ? Or do you have
> concurrency in there...see below.
No, star did not change since the last 15 year:
- One process (the second) read/writes the archive
In copy mode, this process extract the internal stream.
- One process (the first) does the file I/O and archive generation.
> > 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?
> >
>
> 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 ?
What do you believe how fsync is related to POSIX?
When I did introduce fsync calls 7 years ago, I did
make some performance tests and it seems that on UFS, calling
fsync reduces the extract performance by 10-20% which looks OK
to me.
> For NFS, can we make 'tar x' fast and reliable while
> keeping a principle of least surprise for users on
> this non-posix FS.
Someone should start with star -x vs. star -x -no-fsync
tests and report timings...
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
