Toby Thain,
No, physical location was for the exact location and
logical was for the rest of my info.
But, what I might not have made clear was the use of
fragments. Their are two types of fragments. One which
is the partial use of a logical disk block and the other
which I was also trying to refer to is the moving of modified
sections of the file. The first use was well used with
the Joy FFS implementation where a FS and drive tended
to have a high cost per byte overhead and was fairly
small.
Now, lets make this perfectly clear. If a FS object is
large and written "somewhat" in sequence as a stream
of bytes and then random FS logical blocks or physical
blocks are then modified, the new FS object will be less
sequentially written and CAN decrease read performance.
Sorry, I tend to care less about write performance, due
to the fact that writes tend to be async without threads
blocking waiting for their operation to complete.
This will happen MOST as the FS fills and less optimal
locations of the FS are found for the COW blocks.
The same problem happens with memory with OSs that support
multiple page sizes where a well used system may not be
able to allocate large page sizes due to fragmentation.
Yes, this is a overloaded term... :)
Thus, FS performance may suffer even if their are just
alot of 1 byte changes to frequently accessed FS objects.
If this occurs, either keep a larger FS, clean out the
FS more frequently, or backup, cleanup, and then restore
to get newly sequental FS objects.
Mitchell Erblich
-----------------
Toby Thain wrote:
>
> On 28-Feb-07, at 6:43 PM, Erblichs wrote:
>
> > ZFS Group,
> >
> > My two cents..
> >
> > Currently, in my experience, it is a waste of time to try to
> > guarantee "exact" location of disk blocks with any FS.
>
> ? Sounds like you're confusing logical location with physical
> location, throughout this post.
>
> I'm sure Roch meant logical location.
>
> --T
>
> >
> > A simple reason exception is bad blocks, a neighboring block
> > will suffice.
> >
> > Second, current disk controllers have logic that translates
> > and you can't be sure outside of the firmware where the
> > disk block actually is. Yes, I wrote code in this area before.
> >
> > Third, some FSs, do a Read-Modify-Write, where the write is
> > NOT, NOT, NOT overwriting the original location of the read.
> ...
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
