Group,
I am not sure I agree with the 8k size.
Since "recordsize" is based on the size of filesystem blocks
for large files, my first consideration is what will be
the max size of the file object.
For extremely large files (25 to 100GBs), that are accessed
sequentially for both read & write, I would expect 64k or 128k.
Putpage functions attempt to grab a number of pages off the
vnode and place their modified contents within disk blocks.
Thus if disk blocks are larger, then a fewer of them are needed,
and can result in a more efficient operations.
However, any small change to the filesystem block would result
in the entire filesystem block being accessed, so small accesses
to the block are very inefficent.
Lastly, the access to a larger block will occupy the media
for longer periods of continuous time, possibly creating a
larger latency than necessary for another non-related op.
Hope this helps...
Mitchell Erblich
-------------------
Nicolas Williams wrote:
>
> On Fri, Oct 13, 2006 at 08:30:27AM -0700, Matthew Ahrens wrote:
> > Jeremy Teo wrote:
> > >Would it be worthwhile to implement heuristics to auto-tune
> > >'recordsize', or would that not be worth the effort?
> >
> > It would be really great to automatically select the proper recordsize
> > for each file! How do you suggest doing so?
>
> I would suggest the following:
>
> - on file creation start with record size = 8KB (or some such smallish
> size), but don't record this on-disk yet
>
> - keep the record size at 8KB until the file exceeds some size, say,
> .5MB, at which point the most common read size, if there were enough
> reads, or the most common write size otherwise, should be used to
> derive the actual file record size (rounding up if need be)
>
> - if the selected record size != 8KB then re-write the file with the
> new record size
>
> - record the file's selected record size in an extended attribute
>
> - on truncation keep the existing file record size
>
> - on open of non-empty files without associated file record size stick
> to the original approach (growing the file block size up to the FS
> record size, defaulting to 128KB)
>
> I think we should create a namespace for Solaris-specific extended
> attributes.
>
> The file record size attribute should be writable, but changes in record
> size should only be allowed when the file is empty or when the file data
> is in one block. E.g., writing "8KB" to a file's RS EA when the file's
> larger than 8KB or consists of more than one block should appear to
> succeed, but a subsequent read of the RS EA should show the previous
> record size.
>
> This approach might lead to the creation of new tunables for controlling
> the heuristic (e.g., which heuristic, initial RS, file size at which RS
> will be determined, default RS when none can be determined).
>
> Nico
> --
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
