On Mon, 11 Oct 1999, Mikulas Patocka wrote:
> > > > hpfs - no problems, but there is something rather odd. Why on the
> > > > Earth does it forcibly write inode to disk in the end of notify_change()?
> > > > Immediately before that inode is dirtified by inode_setattr(). Mikulas, is
> > > > there something special that makes you write it ASAP?
> > >
> > > HPFS doesn't use write_inode. On HPFS, write_inode needs to lock parent
> > > directory to update dirent. write_inode is called asynchronously and
> > > locking directory makes deadlocks. So, write_inode is NULL and inode is
> > > explicitly written on notify_change and file_release.
> >
> > I see. OK, will it hurt if would do hpfs_truncate() prior to the call of
> > hpfs_file_write()?
>
> What do you mean? truncate and write together will surely cause bad
> things.
I mean the following: assume that call of hpfs_truncate() (via
->truncate()) had been moved into the inode_setattr() (i.e. happens
immediately before the hpfs_write_inode() in hpfs_notify_change()). Will
it have any bad consequences? Right now the sequence looks so:
inode->i_size = newsize;
hpfs_write_inode(inode);
hpfs_truncate(inode);
Could we swap the last steps?
> > I can toss the code for that in - preserving the current behaviour, but
> > allowing to get rid of locking. Would you mind such a variant? It's not
> > like the thing was going to take a lot of time - straightforward copy of
> > FAT version would go.
>
> Do you see any better solution than to go through all btree operations and
> update pointer on every dirent move?
Just put a cyclic list through the inodes referenced from the same
dnode + hash the lists by dnode block number (hash chain going through one
of the cyclic list members, shifted to the neighbor if we are excluding
the thing from cyclic list; the whole mess protected by spinlock). Then
you can quickly find all in-core inodes that belong to any given dnode.
->clear_inode() would exclude the sucker from the lists, all inodes marked
with I_FREEING (i.e. those that gave NULL upon igrab()) are skipped during
the cyclic list searches.
