> > > 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.
> > [ Once you suggested a solution for this - keep in inode pointer to
> > directory data, but I'm too lazy to implement it. HPFS is not performance
> > critical ]
>
> 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?
Mikulas Patocka
