[PATCH] update description in Documentation/filesystems/vfs.txt
While reading the said file I noticed some discrepancies between the actual
code and the info in the docs. Here's an update that attempts to match it to
the code in the current 2.6.22-rc5.
---
From: Borislav Petkov [EMAIL PROTECTED]
Update the description of struct file_system_type and get_sb() in
Documentation/filesystems/vfs.txt to match the current code.
Signed-off-by: Borislav Petkov [EMAIL PROTECTED]
--
Index: linux-2.6.22-rc5/Documentation/filesystems/vfs.txt
===
--- linux-2.6.22-rc5/Documentation/filesystems/vfs.txt.orig 2007-06-24
13:42:40.0 +0200
+++ linux-2.6.22-rc5/Documentation/filesystems/vfs.txt 2007-06-24
14:14:48.0 +0200
@@ -3,7 +3,7 @@
Original author: Richard Gooch [EMAIL PROTECTED]
- Last updated on October 28, 2005
+ Last updated on Juni 24, 2007.
Copyright (C) 1999 Richard Gooch
Copyright (C) 2005 Pekka Enberg
@@ -107,7 +107,7 @@
struct file_system_type
---
-This describes the filesystem. As of kernel 2.6.13, the following
+This describes the filesystem. As of kernel 2.6.22, the following
members are defined:
struct file_system_type {
@@ -119,6 +119,8 @@
struct module *owner;
struct file_system_type * next;
struct list_head fs_supers;
+ struct lock_class_key s_lock_key;
+ struct lock_class_key s_umount_key;
};
name: the name of the filesystem type, such as ext2, iso9660,
@@ -137,11 +139,12 @@
next: for internal VFS use: you should initialize this to NULL
+ s_lock_key, s_umount_key: lockdep-specific
+
The get_sb() method has the following arguments:
- struct super_block *sb: the superblock structure. This is partially
- initialized by the VFS and the rest must be initialized by the
- get_sb() method
+ struct file_system_type *fs_type: decribes the filesystem, partly initialized
+ by the specific filesystem code
int flags: mount flags
@@ -150,12 +153,13 @@
void *data: arbitrary mount options, usually comes as an ASCII
string
- int silent: whether or not to be silent on error
+ struct vfsmount *mnt: a vfs-internal representation of a mount point
The get_sb() method must determine if the block device specified
-in the superblock contains a filesystem of the type the method
-supports. On success the method returns the superblock pointer, on
-failure it returns NULL.
+in the dev_name and fs_type contains a filesystem of the type the method
+supports. If it succeeds in opening the named block device, it initializes a
+struct super_block descriptor for the filesystem contained by the block device.
+On failure it returns an error.
The most interesting member of the superblock structure that the
get_sb() method fills in is the s_op field. This is a pointer to
--
Regards/Gruß,
Boris.
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] fsblock
Nick Piggin [EMAIL PROTECTED] writes: - Structure packing. A page gets a number of buffer heads that are allocated in a linked list. fsblocks are allocated contiguously, so cacheline footprint is smaller in the above situation. It would be interesting to test if that makes a difference for database benchmarks running over file systems. Databases eat a lot of cache so in theory any cache improvements in the kernel which often runs cache cold then should be beneficial. But I guess it would need at least ext2 to test; Minix is probably not good enough. In general have you benchmarked the CPU overhead of old vs new code? e.g. when we went to BIO scalability went up, but CPU costs of a single request also went up. It would be nice to not continue or better reverse that trend. - Large block support. I can mount and run an 8K block size minix3 fs on my 4K page system and it didn't require anything special in the fs. We can go up to about 32MB blocks now, and gigabyte+ blocks would only require one more bit in the fsblock flags. fsblock_superpage blocks are PAGE_CACHE_SIZE, midpage ==, and subpage . Can it be cleanly ifdefed or optimized away? Unless the fragmentation problem is not solved it would seem rather pointless to me. Also I personally still think the right way to approach this is larger softpage size. -Andi - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 1/3] add the fsblock layer
Nick Piggin [EMAIL PROTECTED] writes:
[haven't read everything, just commenting on something that caught my eye]
+struct fsblock {
+ atomic_tcount;
+ union {
+ struct {
+ unsigned long flags; /* XXX: flags could be int for
better packing */
int is not supported by many architectures, but works on x86 at least.
Hmm, could define a macro DECLARE_ATOMIC_BITMAP(maxbit) that expands to the
smallest
possible type for each architecture. And a couple of ugly casts for set_bit
et.al.
but those could be also hidden in macros. Should be relatively easy to do.
-Andi
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 1/3] add the fsblock layer
Hmm, could define a macro DECLARE_ATOMIC_BITMAP(maxbit) that expands to the smallest possible type for each architecture. And a couple of ugly casts for set_bit et.al. but those could be also hidden in macros. Should be relatively easy to do. or make a smallbit type that is small/supported, so 64 bit if 32 bit isn't supported, otherwise 32 - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
Hi! But as someone who doesn't use either SElinux or AA, I really hope we can get past the part of the debate where: while(1) AA) we think we're making users happy with pathname security SELINUX) pathname security sucks (Hopefully I'll not be fired for this. :-) Yes, we _are_ making users happy with AA. Questions is if we are making them secure. :-). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 1/3] add the fsblock layer
On Sunday June 24, [EMAIL PROTECTED] wrote: +#define PG_blocks20 /* Page has block mappings */ + I've only had a very quick look, but this line looks *very* wrong. You should be using PG_private. There should never be any confusion about whether -private has buffers or blocks attached as the only routines that ever look in -private are address_space operations (or should be. I think 'NULL' is sometimes special cased, as in try_to_release_page. It would be good to do some preliminary work and tidy all that up). Why do you think you need PG_blocks? NeilBrown - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
