View Incident:
http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=797165
Submitter : nathans Submitter Domain : engr
Assigned Engineer : btg Assigned Domain : sgi.com
Assigned Group : xfs-linux Category : software
Customer Reported : F Priority : 4
Project : xfs-linux Status : open
Description :
stick this in a bug so it isn't forgotten...
On Jul 21, 8:40am, Nathan Scott wrote:
> Subject: Re: LVM vs. kiobuf I/O
> > > - Kernel uuid generation support
> > ...
> ...
>
> I think there's a bunch of stuff which can be rationalised
> there too...
> - uuid_hash is unused, can definately go;
> - uuid_hash64 is only used in xfs_mountfs_int to setup vfs_fsid
> (of vfs_t), which doesn't seem to be doing much useful, so
> that can probably go;
> - if that can go, we can probably remove all of xfs_uuid_mount,
> since its only ever called to setup vfs_fsid ... and so I
> wonder do we need xfs_uuidtabmon, xfs_uuidtab_size, and
> xfs_uuidtab anymore, along with the associated unmount logic?
> - then we could go back and see what uuid code we still need
> (uuid_create still used in xfs_inode.c, icalloc, IFMNT case;
> but there's probably not much else needed)
>
> Anyone who knows the mount code better than me have thoughts
> on this (have I missed a dependence above)? Is this something
> we'll need later perhaps, or can this stuff all really go?
>
>
> thanks.
>
> --
> Nathan
>-- End of excerpt from Nathan Scott
|