Hi,
On Mon, 11 Oct 1999 11:12:01 -0400 (EDT), Alexander Viro
<[EMAIL PROTECTED]> said:
> I began screwing around the truncate() stuff and the following is
> a status report/request for comments:
> a) call of ->truncate() method (and vmtruncate()) had been moved
> into the notify_change(). It is triggered if ATTR_SIZE is set. Modified
> places: do_truncate(), nfsd_truncate(), nfsd_setattr() and hpfs_unlink().
> Semantics had been changed (fixed, AFAICS) for nfsd_* - truncation happens
> with capabilities dropped. BTW, nfsd_setattr() didn't call vmtruncate().
> Fixed.
The page cache has very strict ordering requirements on the
inode->i_size update, the vmtruncate call and the actual file mapping
truncate operation. I'd be nervous about letting the fs do too much of
that itself: what exactly is the rationale behind the change?
> coda,nfs,ncpfs,smbfs - I'm bringing the call of vmtruncate() into
> the end of ->notify_change() (if ATTR_SIZE is set, indeed). It preserves
> the current behaviour, but I'm not sure that it's OK. Those filesystems
> don't have ->truncate() and do the equivalent theselves (from
> -> notify_change()). Maybe vmtruncate() should be called earlier.
Given that we are already looking at adding back in the inode write lock
for truncate, that shouldn't be a problem.
--Stephen
