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

List:       linux-fsdevel
Subject:    Re: [RFC] truncate() (generic stuff)
From:       Alexander Viro <viro () math ! psu ! edu>
Date:       1999-10-12 16:16:53
[Download RAW message or body]



On Tue, 12 Oct 1999, Stephen C. Tweedie wrote:

> Hi,
> 
> On Tue, 12 Oct 1999 09:37:28 -0400 (EDT), Alexander Viro
> <viro@math.psu.edu> said:
> 
> > 	Rationale was:
> > 	a) get rid of code duplication and get all calls of ->truncate()
> > into the same place.
> > 	b) make it in the same place that sets i_size.
> > 	c) on many filesystems extending ->truncate() may fail. Right now
> > we have no way to report said fact (or any other errors, for that matter).
> > Change will be easier if we will have _one_ place to look after.
> 
> Yes, and I had to make similar changes in 2.2 to report such changes.
> Observing RLIMIT_FSIZE in the filesystem requires that, for example.
> However, 2.3 is a lot more sensitive to the ordering.
> 
> > 	IMHO it became cleaner - I can post the detailed proof that it
> > preserves the ordering. It was a requirement from the very beginning.
> 
> Fine, as long as we document somewhere exactly what the filesystem
> requirements are.

Filesystem can either:
	a) set ->notify_change to NULL or
	b) call in ->notify_change() inode_setattr() (which will do the
right thing wrt truncation - set i_size, call vmtruncate() and
->truncate()) and keep in mind that upon the return from inode_setattr()
file is already truncated or
	c) take care to set i_size by hands and at the end of
->notify_change() (if it didn't fail so far and had been asked to change
size) do vmtruncate() followed by fs-specific metadata modifications
needed for truncation (if they are needed at all - right now none of the
filesystems in that category (nfs,coda,ncpfs and smbfs) has such need)

	In other words, impact on existing filesystems was minimal. I've
added the call of vmtruncate() into the end of ->notify_change() for coda,
nfs, ncpfs and smbfs + made a couple of cleanups in affs and hpfs (not
strictly needed - see the final variant of patch for details). That was
it.

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