> 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?
Probably yes, the first hpfs_write_inode is not needed at all.
> > > 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.
You can do the same just by examining content of dnode (dirents have fnode
numbers).
> ->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.
There is another clash if you use async write_inode. Somebody is modifying
directory, btree operation is in progress and now - system decides to call
write_inode. You can't wait in write_inode until directory is in
consistent state, you just must patch dirent somwhere in memory and
return. That means - inode must hold pointer to dirent on disk or in
memory.
It is possible to write it, but HPFS is currently very stable and
race-free (the last race I had was bug in kernel) and such modifications
would surely make a lot of problems.
Mikulas Patocka
