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

David Chow (davidchow@rcn.com.hk)
Tue, 01 Jan 2002 11:55:16 +0800


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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/