[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-fsdevel
Subject:    Re: fs/ext2/inode.c:ext2_notify_change()
From:       Daniel Phillips <news-innominate.list.linux.fsdevel () innominate ! de>
Date:       2000-11-24 11:10:19
[Download RAW message or body]

Alexander Viro wrote:
> 
> On Thu, 23 Nov 2000, Daniel Phillips wrote:
> 
> > Not strictly related to ext2, but having sys_truncate call vmtruncate
> > via notify_change seems like a bizarre arrangement that could be cleaned
> > up.  There are filesystems that rely on this behaviour (once again NFS
> > rears its head) but in the common case where ->setattr isn't being
> > overriden we could take a much more direct path to vmtruncate.
> 
> a) we need to override it on ext2, UFS and minix.
> b) combined with the cases that already have ->setattr() it leaves only
> qnx4, UDF and procfs ones. The latter _need_ ->setattr() - one that would
> refuse to change ->i_size.
> 
> IOW, your "much more direct path" would be taken in (at most) two cases.
> And that - only if qnxfs and UDF are able to support really large files.
> I doubt that they are.

Ext2 doesn't use ->setattr.  We use it in the Ext2 tailmerge patch only
because it's the only way to intercept a truncate.  I'd much prefer that
there were a defined truncate method (presumeably pointing to vmtruncate
- or a slight variation that also updates the inode time fields) and
that both sys_truncate and notify_change would call that.  As it stands,
in order to do the interception we have to decode the struct iattr
command packet thingy and this just seems complex and fragile.

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org

[prev in list] [next in list] [prev in thread] [next in thread]