Frank Penczek writes:
> Hi,
>
> On Dec 17, 2007 4:18 PM, Roch - PAE <[EMAIL PROTECTED]> wrote:
> > >
> > > The pool holds home directories so small sequential writes to one
> > > large file present one of a few interesting use cases.
> >
> > Can you be more specific here ?
> >
> > Do you have a body of application that would do small
> > sequential writes; or one in particular ? Another
> > interesting info is if we expect those to be allocating
> > writes or overwrite (beware that some app, move the old file
> > out, then run allocating writes, then unlink the original
> > file).
>
> Sorry, I try to be more specific.
> The zpool contains home directories that are exported to client machines.
> It is hard to predict what exactly users are doing, but one thing users do
> for
> certain is checking out software projects from our subversion server. The
> projects typically contain many source code files (thousands) and a
> build process
> accesses all of them in the worst case. That is what I meant by "many (small)
> files like compiling projects" in my previous post. The performance
> for this case
> is ... hopefully improvable.
>
This we'll have to work on. But first, If this is to
Storage with NVRAM, I assume you checked that the storage
does not flush it's caches :
http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide#Cache_Flushes
If that is not your problem and if ZFS underperform another
FS on the backend of NFS, then this needs investigation.
If ZFS/NFS underperformance a direct attach FS that might
just be an NFS issue not related to ZFS. Again that needs
investigation.
Performance gains won't happen unless we find out what
doesn't work.
> Now for sequential writes:
> We don't have a specific application issuing sequential writes but I
> can think of
> at least a few cases where these writes may occur, e.g.
> dumps of substantial amounts of measurement data or growing log files
> of applications.
> In either case these would be mainly allocating writes.
>
Right but I'd hope the application would issue substantially
large writes specially if it' needs to dump data at high rate.
If the data rate is more modest, then the CPU lost to this
effect will itself be modest.
> Does this provide the information you're interested in?
>
I get a sense that it's more important we find out what is
your build issue is. But the small writes will have to be
improved one day also.
-r
>
> Cheers,
> Frank
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
