Nico,
Yes, I agree.
But also single random large single read and writes would also
benefit from a large record size. So, I didn't try make that
distinction. However, I "guess" that the best random large
reads & writes would fall within single filesystem record
sizes.
No, I haven't reviewed whether the holes (disk block space)
tend to be multiples of record size, page size, or ..
Would a write of recordsize that didn't fall on a record size
boundry write into 2 filesystem blocks / records?
However, would extremely large record sizes, say 1MB (or more)
(what is the limit?), open up write atomicity issues
or file corruption issues? Would record sizes like these
be equal to mulitple track writes?
Also, because of the "disk block" allocation stategy, I
wasn't too sure that any form of multiple disk block
contigousness still applied with ZFS with smaller record
sizes.. Yes, to minimize seek and rotational latencies
and help with read ahead and "write behind"...
Oh, but once writes have begun to the file, in the past,
this has frozen the recordsize. So "self-tuning" or
adjustments NEED to be decided probably at the create
of the FS object. OR some type of copy mechanism needs to
be done to a new file with a different record size at a
later time when the default or past record size was
determined to be significantly incorrect. Yes, I assume
that many reads /writes will occur in the future that
will amortize the copy cost.
So, yes group... I am still formulating the "best"
algorithm for this. ZFS uses alot of past gained
knowledege applied to UFS (page lists stuff, chksum stuff,
large file awwareness/support), but adds a new twist to
things..
Mitchell Erblich
------------------
Nicolas Williams wrote:
>
> On Fri, Oct 13, 2006 at 09:22:53PM -0700, Erblichs wrote:
> > For extremely large files (25 to 100GBs), that are accessed
> > sequentially for both read & write, I would expect 64k or 128k.
>
> Lager files accessed sequentially don't need any special heuristic for
> record size determination: just use the filesystem's record size and be
> done. The bigger the record size, the better -- a form of read ahead.
>
> Nico
> --
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
