On Tue, 01 Aug 2000, Chris Mason wrote:
> On 8/1/00, 2:45:11 PM, Daniel Phillips <[EMAIL PROTECTED]>
> > writing past tail?
> > if so, unmerge tail block
> > generic file write
>
> > additions to write full page:
> > (within the per-buffer write)
> > is the file tailmerged?
> > if so, does this part map the tail block?
> > if so, get the tail block and copy the tail to the page
>
> Hmmm, I'm confused by the above. If write full page copies the tail onto
> the page (without unmerging it), how does the data get back to disk?
I accidently interchanged the description of the read and write. That
should clear some things up. :-)
> > This doesn't attempt to do the tail merge incrementally - instead it's
> > going to be done at mount time, just for the prototype.
>
> > Implications of sharing tail blocks between files:
> > - must unmerge on truncate (except when truncate is within tail)
>
> I can only think of 4 cases for the truncate:
>
> truncate within tail (can stay merged)
> truncate completely removes tail (nothing to unmerge)
> truncate completely removes tail and X bytes before it (nothing to
> unmerge)
Where you wrote "nothing to unmerge", actually what you have to do there is
unlink the current inode from the merge ring. In fact, apart from clearing the
offset field, that's the entire unmerge operation in my scheme.
> truncate removes enough data that you want to create a new tail (might
> want to merge)
Yes. My plan is to defer the implementation of merge-on-the-fly until after
the merge-on-mount prototype is implemented. That will allow a little extra
time to discuss it and make some sensible design decisions. Not to mention
being able to base the decisions on experience.
So I guess that discussion has already started: I'm not sure exactly when the
best time to merge is. I'm thinking about it, I'm not ready to say anything
intelligent yet, and I'd appreciate comments.
> > - Two processes attempting to unmerge at the same time could
> > deadlock, as each of them might attempts to lock the same
> > two inodes to perform a ring delete, and each succeed in
> > getting only one of them. This impasse has to be resolved
> > in some deterministic way.
>
> It seems that you should be able to order the locks by inode number.
Yes, that solves it. Actually, there are three inodes involved - the current
one, and prev and next in the ring. Ordering by inode number also solves that.
--
Daniel
