[lkml]   [2002]   [Apr]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [prepatch] address_space-based writeback

I am cc:-ing Al Viro, perhaps Al could comment on approach as this would
affect the future of read_inode2 in VFS?

At 10:03 29/04/02, Nikita Danilov wrote:
>Anton Altaparmakov writes:
> > At 16:53 27/04/02, Jan Harkes wrote:
> > >You could have all additional IO streams use the same inode number and
> > >use iget4. Several inodes can have the same i_ino and the additional
> > >argument would be a stream identifier that selects the correct 'IO
> > >identity'.
> >
> > Great idea! I quickly looked into the implementation details and using
> > iget4/read_inode2 perfectly reconciles my ideas of using an address space
> > mapping for each ntfs attribute with the kernels requirement of using
> > inodes as the i/o entity by allowing a clean and unique mapping between
> > multiple inodes with the same inode numbers and their attributes and
> > address spaces.
>Please note that ->read_inode2() is reiserfs-specific hack. Adding more
>users for it would make it permanent. The only reason for ->read_inode2
>existence was that iget() was called by code external to the
>file-system, knfsd used to do this, now it can call ->fh_to_dentry() in
>stead. As iget() is never called outside of file-ssytem, you can set
>ntfs->read_inode to no-op and write your own function ntfs_iget(...) to
>be called from ntfs_lookup() and ntfs_fill_super().
>ntfs_iget() calls iget() (->read_inode is no-op, hence iget doesn't
>access disk) and, if new inode were allocated, reads data from the disk
>and initializes inode, etc.
>I guess coda_iget() is example of this.

This will not work AFAICS.

coda_iget() -> iget4() -> get_new_inode(), which calls ->read_inode or
->read_inode2, and then unlocks the inode and wakes up the waiting tasks.

If ->read_inode and ->read_inode2 are NULL as you suggest for NTFS it means
that as soon as ntfs_iget() has called iget4() there will be an
uninitialized yet unlocked inode in memory which is guaranteed to cause
NTFS to oops... (And any other fs using this approach.)

Before the inode is unlocked it MUST be initialized. And the only way to do
this in the framework of the current VFS is to use ->read_inode or

Al, would you agree with NTFS using ->read_inode2 as well as ReiserFS?

Best regards,


"I've not lost my mind. It's backed up on tape somewhere." - Unknown
Anton Altaparmakov <aia21 at> (replace at with @)
Linux NTFS Maintainer / IRC: #ntfs on
WWW: &

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:22    [W:0.173 / U:0.992 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site