Re: [RFC] [WIP] Unbork fs.h, 3 of 3

[David Chow <davidchow@rcn.com.hk>]

Just some comments and questions about the new fs.h .. its great to hear 
improvements in the new year!

Are you people going to put this on the 2.5? It seems you are keeping 
the generic_ip pointer for compatibility. And I guess this is what other 
file systems (those not included in the standardkernel sources) are 
using, at least I am the one.

Daniel Phillips wrote:

>On December 31, 2001 07:16 pm, Linus Torvalds wrote:
>
>>How about using a descriptor structure instead of the macro, and making
>>the filesystem declaration syntax look more like
>>
>>	static struct file_system_type ext2_descriptor = {
>>		owner:		THIS_MODULE,
>>		fs_flags:	FS_REQUIRES_DEV,
>>		name:		"ext2",
>>		read_super:	ext2_read_super,
>>		super_size:	sizeof(ext2_sb_info),
>>
>		^^^^^---> changed sb to super, lines up better
>
>>		inode_size:	sizeof(struct ext2_inode_info)
>>	};
>>
I am using the generic_ip to hold my fs inode data pointer. During the 
implementation, I tested both approaches... but it seems not sigficant 
in detection of inode cache allocation overheads in read_inode(). Its 
worth to talk about memory consumptions because it is silly to allocate 
the largest possible inode cache sizes. I strongly agree with the new fs 
declaration interface becuase of higher efficiency and less overhead, 
but it seems more and more fs are supported in Linux, the effort to 
patch all fs'es is a lot of work.

I am working on a compression file systmes, many thing varies such that 
I have to use dynamically link allocated structures in the inode cache.

>>
>>which is more readable, and inherently documents _what_ those things are.
>>
>>[snip halfway macro format]
>>
>>What do you think?
>>
>
>It's much nicer, here's (1 of 3) again, with the Linus-style ext2_fs
>declaration.
>
>--
>Daniel
>
For the remount issue, I don't think its just affect the root 
filesystem, for me I also reload other settings during a remount. For 
feature oriented filesystems, remount may be use more frequent then 
umount and mount. Other admins may also remount their /usr fs and other 
protected fs to read-only for safe after altering their fs. Why not 
changing the remount behaviour in VFS not to call module_exit()? I also 
can't see why VFS has to call module_exit() in remount if we have 
remount() in super_operations ... I think remount operations are fs 
specific and shuold pass this job to super_operations->remount . I think 
it is a better way to solve the root fs problem. But it would require 
even more work to get all fs to obey the new standard. If you want nice 
and clean efficient solutions, work is must anyway... good luck.

David Chow