exofs for kernel 2.6.30
Subsystems (3)
cover exofs for kernel 2.6.30
What's new since last iteration:
* I completely re-wrote the [PATCH 4/8] exofs: address_space_operations in which we actually write/read to/from osd-storage. The difference is that now we try to accumulate as many contiguous pages as possible and send them as one large request. As opposed to writing each page at a time, in the previous patchset.
* [PATCH 5/8] exofs: dir_inode and directory operations received lots of love thanks to Evgeniy Polyakov's grate comments.
exofs is a file system that uses an OSD device as it's back store.
OSD is a new T10 command set that views storage devices not as a large/flat array of sectors but as a container of objects, each having a length, quota, time attributes and more. Each object is addressed by a 64bit ID, and is contained in a 64bit ID partition. Each object has associated attributes attached to it, which are integral part of the object and provide metadata about the object. The standard defines some common obligatory attributes, but user attributes can be added as needed.
Here is the list of patches
[PATCH 1/8] exofs: Kbuild, Headers and osd utils
[PATCH 2/8] exofs: file and file_inode operations [PATCH 3/8] exofs: symlink_inode and fast_symlink_inode operations [PATCH 4/8] exofs: address_space_operations
[PATCH 5/8] exofs: dir_inode and directory operations [PATCH 6/8] exofs: super_operations and file_system_type [PATCH 7/8] exofs: Documentation
[PATCH 8/8] fs: Add exofs to Kernel build
This patchset is also available on:
git-clone git://git.open-osd.org/linux-open-osd.git linux-next
or on the web at:
http://git.open-osd.org/gitweb.cgi?p=linux-open-osd.git;a=shortlog;h=refs/heads/linux-next
(Above tree is based on Linus v2.6.29-rc8-212-g8144737)
If anyone wants to actually run this code and test it then please start reading at:
http://open-osd.org
You will need to checkout the out-of-tree git (below) for the user-mode utilities. Also the exofs.txt file in patch 7/8 should help
If you want to review the user-mode library and supporting plumbings,
git-clone git://git.open-osd.org/open-osd.git
or on the web at:
http://git.open-osd.org/gitweb.cgi?p=open-osd.git;a=summary
Boaz
PATCH 1/8 exofs: Kbuild, Headers and osd utils
This patch includes osd infrastructure that will be used later by the file system.
Also the declarations of constants, on disk structures, and prototypes.
And the Kbuild+Kconfig files needed to build the exofs module.
--- fs/exofs/Kbuild | 30 +++++++++ fs/exofs/Kconfig | 13 ++++ fs/exofs/common.h | 185 +++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/exofs/exofs.h | 127 ++++++++++++++++++++++++++++++++++++ fs/exofs/osd.c | 153 +++++++++++++++++++++++++++++++++++++++++++ 5 files changed, 508 insertions(+), 0 deletions(-) create mode 100644 fs/exofs/Kbuild create mode 100644 fs/exofs/Kconfig create mode 100644 fs/exofs/common.h create mode 100644 fs/exofs/exofs.h create mode 100644 fs/exofs/osd.c
fs/exofs/Kbuild new file +30 -0
@@ -0,0 +1,30 @@ +# +# Kbuild for the EXOFS module +# +# Copyright (C) 2008 Panasas Inc. All rights reserved. +# +# Authors: +# Boaz Harrosh <[email protected]> +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License version 2 +# +# Kbuild - Gets included from the Kernels Makefile and build system +# + +ifneq ($(OSD_INC),) +# we are built out-of-tree Kconfigure everything as on + +CONFIG_EXOFS_FS=m +ccflags-y += -DCONFIG_EXOFS_FS -DCONFIG_EXOFS_FS_MODULE +# ccflags-y += -DCONFIG_EXOFS_DEBUG + +# if we are built out-of-tree and the hosting kernel has OSD headers +# then "ccflags-y +=" will not pick the out-off-tree headers. Only by doing +# this it will work. This might break in future kernels +KBUILD_CPPFLAGS := -I$(OSD_INC) $(KBUILD_CPPFLAGS) + +endif + +exofs-y := osd.o +obj-$(CONFIG_EXOFS_FS) += exofs.o
fs/exofs/Kconfig new file +13 -0
@@ -0,0 +1,13 @@ +config EXOFS_FS + tristate "exofs: OSD based file system support" + depends on SCSI_OSD_ULD + help + EXOFS is a file system that uses an OSD storage device, + as its backing storage. + +# Debugging-related stuff +config EXOFS_DEBUG + bool "Enable debugging" + depends on EXOFS_FS + help + This option enables EXOFS debug prints.
fs/exofs/common.h new file +185 -0
185 lines not on this page · raw message
fs/exofs/exofs.h new file +127 -0
127 lines not on this page · raw message
fs/exofs/osd.c new file +153 -0
153 lines not on this page · raw message
Signature · 1 line
1.6.2.1
PATCH 1/8 exofs: Kbuild, Headers and osd utils
In reply to Boaz HarroshThis patch includes osd infrastructure that will be used later by the file system.
Also the declarations of constants, on disk structures, and prototypes.
And the Kbuild+Kconfig files needed to build the exofs module.
--- fs/exofs/Kbuild | 30 +++++++++ fs/exofs/Kconfig | 13 ++++ fs/exofs/common.h | 185 +++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/exofs/exofs.h | 127 ++++++++++++++++++++++++++++++++++++ fs/exofs/osd.c | 153 +++++++++++++++++++++++++++++++++++++++++++ 5 files changed, 508 insertions(+), 0 deletions(-) create mode 100644 fs/exofs/Kbuild create mode 100644 fs/exofs/Kconfig create mode 100644 fs/exofs/common.h create mode 100644 fs/exofs/exofs.h create mode 100644 fs/exofs/osd.c
fs/exofs/Kbuild new file +30 -0
@@ -0,0 +1,30 @@ +# +# Kbuild for the EXOFS module +# +# Copyright (C) 2008 Panasas Inc. All rights reserved. +# +# Authors: +# Boaz Harrosh <[email protected]> +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License version 2 +# +# Kbuild - Gets included from the Kernels Makefile and build system +# + +ifneq ($(OSD_INC),) +# we are built out-of-tree Kconfigure everything as on + +CONFIG_EXOFS_FS=m +ccflags-y += -DCONFIG_EXOFS_FS -DCONFIG_EXOFS_FS_MODULE +# ccflags-y += -DCONFIG_EXOFS_DEBUG + +# if we are built out-of-tree and the hosting kernel has OSD headers +# then "ccflags-y +=" will not pick the out-off-tree headers. Only by doing +# this it will work. This might break in future kernels +KBUILD_CPPFLAGS := -I$(OSD_INC) $(KBUILD_CPPFLAGS) + +endif + +exofs-y := osd.o +obj-$(CONFIG_EXOFS_FS) += exofs.o
fs/exofs/Kconfig new file +13 -0
@@ -0,0 +1,13 @@ +config EXOFS_FS + tristate "exofs: OSD based file system support" + depends on SCSI_OSD_ULD + help + EXOFS is a file system that uses an OSD storage device, + as its backing storage. + +# Debugging-related stuff +config EXOFS_DEBUG + bool "Enable debugging" + depends on EXOFS_FS + help + This option enables EXOFS debug prints.
fs/exofs/common.h new file +185 -0
185 lines not on this page · raw message
fs/exofs/exofs.h new file +127 -0
127 lines not on this page · raw message
fs/exofs/osd.c new file +153 -0
153 lines not on this page · raw message
Signature · 1 line
1.6.2.1
Re: [PATCH 1/8] exofs: Kbuild, Headers and osd utils
Quoted 30 lines · On Wed, 18 Mar 2009 19:57:36 +0200 Boaz Harrosh <[email protected]> wrote:
This patch includes osd infrastructure that will be used later by the file system.
Also the declarations of constants, on disk structures, and prototypes.
And the Kbuild+Kconfig files needed to build the exofs module.
...
fs/exofs/Kbuild new file +17
-0@@ -0,0 +1,30 @@ +# +# Kbuild for the EXOFS module +# +# Copyright (C) 2008 Panasas Inc. All rights reserved. +# +# Authors: +# Boaz Harrosh <[email protected]> +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License version 2 +# +# Kbuild - Gets included from the Kernels Makefile and build system +# + +ifneq ($(OSD_INC),) +# we are built out-of-tree Kconfigure everything as on +
fs/exofs/Kbuild line 27
Quoted 10 lines
fs/exofs/Kbuild new file +10
-0+CONFIG_EXOFS_FS=m +ccflags-y += -DCONFIG_EXOFS_FS -DCONFIG_EXOFS_FS_MODULE +# ccflags-y += -DCONFIG_EXOFS_DEBUG + +# if we are built out-of-tree and the hosting kernel has OSD headers +# then "ccflags-y +=" will not pick the out-off-tree headers. Only by doing +# this it will work. This might break in future kernels +KBUILD_CPPFLAGS := -I$(OSD_INC) $(KBUILD_CPPFLAGS) + +endif
But this patch is putting the fs into the tree, so all the above is unneeded.
fs/exofs/Kbuild
Quoted 7 lines
...
+ * Object IDs 0, 1, and 2 are always in use (see above defines).
+ */fs/exofs/Kbuild new file +2
-0+enum { + EXOFS_UINT64_MAX = (~0LL),
Use ULLONG_MAX?
~0ULL would be more consistent.
fs/exofs/Kbuild
Quoted 2 lines
fs/exofs/Kbuild new file +2
-0+ EXOFS_MAX_INO_ID = (sizeof(ino_t) * 8 == 64) ? EXOFS_UINT64_MAX : + (1LL << (sizeof(ino_t) * 8 - 1)),
Tricky, needs a comment.
Would be clearer to use 1ULL.
fs/exofs/Kbuild
Quoted 13 lines
fs/exofs/Kbuild new file +13
-0+ EXOFS_MAX_ID = (EXOFS_MAX_INO_ID - 1 - EXOFS_OBJ_OFF), +}; + +/**************************************************************************** + * Misc. + ****************************************************************************/ +#define EXOFS_BLKSHIFT 12 +#define EXOFS_BLKSIZE (1UL << EXOFS_BLKSHIFT) + +/**************************************************************************** + * superblock-related things + ****************************************************************************/ +#define EXOFS_SUPER_MAGIC 0x5DF5
Should be in include/linux/magic.h
Quoted 10 lines
...
fs/exofs/Kbuild new file +7
-0+/* + * The file control block - stored in an object's attributes. This is where + * the in-memory inode is stored on disk. + */ +struct exofs_fcb { + __le64 i_size; /* Size of the file */ + __le16 i_mode; /* File mode */
fs/exofs/Kbuild
Quoted 10 lines
fs/exofs/Kbuild new file +10
-0+ __le16 i_links_count; /* Links count */ + __le32 i_uid; /* Owner Uid */ + __le32 i_gid; /* Group Id */ + __le32 i_atime; /* Access time */ + __le32 i_ctime; /* Creation time */ + __le32 i_mtime; /* Modification time */ + __le32 i_flags; /* File flags (unused for now)*/ + __le32 i_generation; /* File version (for NFS) */ + __le32 i_data[EXOFS_IDATA]; /* Short symlink names and device #s */ +};
There is no room for future expansion. Would that be appropriate/wise? I guess it would need versioning information somewhere too.
fs/exofs/Kbuild
Quoted 5 lines
...
fs/exofs/Kbuild new file +2
-0+/* u64 has problems with printk this will cast it to unsigned long long */ +#define _LLU(x) (unsigned long long)(x)
ug.
Normally the response is "please open-code this". But given that one day real soon this printk(u64) problem will be fixed, I guess the use of _LLU will make it easy to find and delete all the now-unneeded casts.
fs/exofs/Kbuild
Quoted 13 lines
...
fs/exofs/Kbuild new file +10
-0+/* + * our inode flags + */ +#define OBJ_2BCREATED 0 /* object will be created soon*/ +#define OBJ_CREATED 1 /* object has been created on the osd*/ + +static inline int obj_2bcreated(struct exofs_i_info *oi) +{ + return test_bit(OBJ_2BCREATED, &(oi->i_flags)); +}
unneeded parentheses around oi->i_flags.
Quoted 4 lines
fs/exofs/Kbuild new file +4
-0+static inline void set_obj_2bcreated(struct exofs_i_info *oi) +{ + set_bit(OBJ_2BCREATED, &(oi->i_flags)); +}
fs/exofs/Kbuild
Quoted 10 lines
fs/exofs/Kbuild new file +10
-0+ +static inline int obj_created(struct exofs_i_info *oi) +{ + return test_bit(OBJ_CREATED, &(oi->i_flags)); +} + +static inline void set_obj_created(struct exofs_i_info *oi) +{ + set_bit(OBJ_CREATED, &(oi->i_flags)); +}
dittoes.
Quoted 3 lines
...
Re: [PATCH 1/8] exofs: Kbuild, Headers and osd utils
Quoted 61 lines · Andrew Morton
Quoted 30 lines · On Wed, 18 Mar 2009 19:57:36 +0200 Boaz Harrosh <[email protected]> wrote:
This patch includes osd infrastructure that will be used later by the file system.
Also the declarations of constants, on disk structures, and prototypes.
And the Kbuild+Kconfig files needed to build the exofs module.
...
fs/exofs/Kbuild new file +17
-0@@ -0,0 +1,30 @@ +# +# Kbuild for the EXOFS module +# +# Copyright (C) 2008 Panasas Inc. All rights reserved. +# +# Authors: +# Boaz Harrosh <[email protected]> +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License version 2 +# +# Kbuild - Gets included from the Kernels Makefile and build system +# + +ifneq ($(OSD_INC),) +# we are built out-of-tree Kconfigure everything as on +fs/exofs/Kbuild line 27
Quoted 10 lines
fs/exofs/Kbuild new file +10
-0+CONFIG_EXOFS_FS=m +ccflags-y += -DCONFIG_EXOFS_FS -DCONFIG_EXOFS_FS_MODULE +# ccflags-y += -DCONFIG_EXOFS_DEBUG + +# if we are built out-of-tree and the hosting kernel has OSD headers +# then "ccflags-y +=" will not pick the out-off-tree headers. Only by doing +# this it will work. This might break in future kernels +KBUILD_CPPFLAGS := -I$(OSD_INC) $(KBUILD_CPPFLAGS) + +endifBut this patch is putting the fs into the tree, so all the above is unneeded.
fs/exofs/Kbuild
Quoted 6 lines
...
+ * Object IDs 0, 1, and 2 are always in use (see above defines).
+ */fs/exofs/Kbuild new file +2
-0+enum { + EXOFS_UINT64_MAX = (~0LL),Use
ULLONG_MAX?~0ULL would be more consistent.
fs/exofs/Kbuild
Quoted 2 lines
fs/exofs/Kbuild new file +2
-0+ EXOFS_MAX_INO_ID = (sizeof(ino_t) * 8 == 64) ? EXOFS_UINT64_MAX : + (1LL << (sizeof(ino_t) * 8 - 1)),Tricky, needs a comment.
Quoted 5 lines
Would be clearer to use 1ULL.
fs/exofs/Kbuild
Quoted 3 lines
fs/exofs/Kbuild new file +3
-0+ EXOFS_MAX_ID = (EXOFS_MAX_INO_ID - 1 - EXOFS_OBJ_OFF), +}; +
OK, OK, OK
Quoted 4 lines
Quoted 4 lines
fs/exofs/Kbuild new file +4
-0+/**************************************************************************** + * Misc. + ****************************************************************************/ +#define EXOFS_BLKSHIFT 12
Quoted 9 lines
fs/exofs/Kbuild
Quoted 6 lines
fs/exofs/Kbuild new file +6
-0+#define EXOFS_BLKSIZE (1UL << EXOFS_BLKSHIFT) + +/**************************************************************************** + * superblock-related things + ****************************************************************************/ +#define EXOFS_SUPER_MAGIC 0x5DF5Should be in
include/linux/magic.h
Is this relevant for OSD, I guess if there are going to be more OSD filesystems then yes.
I will do it, thanks.
Quoted 14 lines
Quoted 14 lines
...
fs/exofs/Kbuild new file +12
-0+/* + * The file control block - stored in an object's attributes. This is where + * the in-memory inode is stored on disk. + */ +struct exofs_fcb { + __le64 i_size; /* Size of the file */ + __le16 i_mode; /* File mode */ + __le16 i_links_count; /* Links count */ + __le32 i_uid; /* Owner Uid */ + __le32 i_gid; /* Group Id */ + __le32 i_atime; /* Access time */ + __le32 i_ctime; /* Creation time */
Quoted 9 lines
fs/exofs/Kbuild
Quoted 5 lines
fs/exofs/Kbuild new file +5
-0+ __le32 i_mtime; /* Modification time */ + __le32 i_flags; /* File flags (unused for now)*/ + __le32 i_generation; /* File version (for NFS) */ + __le32 i_data[EXOFS_IDATA]; /* Short symlink names and device #s */ +};There is no room for future expansion. Would that be appropriate/wise? I guess it would need versioning information somewhere too.
In osd we have the size-of-the-attribute it sits in. So if in future we add members we can switch according to size, also we can just stick it in a different attribute number, so like EXOFS_ATTR_INODE_DATA_VER1 EXOFS_ATTR_INODE_DATA_VER2 attribute. Presence of, means support. Hell we can even be backward compatible with having 2 or three versions at once.
Quoted 7 lines
fs/exofs/Kbuild
Quoted 4 lines
...
fs/exofs/Kbuild new file +2
-0+/* u64 has problems with printk this will cast it to unsigned long long */ +#define _LLU(x) (unsigned long long)(x)ug.
Quoted 5 lines
Normally the response is "please open-code this". But given that one day real soon this printk(u64) problem will be fixed, I guess the use of
_LLUwill make it easy to find and delete all the now-unneeded casts.
Exactly my thoughts
Quoted 15 lines
fs/exofs/Kbuild
Quoted 12 lines
...
fs/exofs/Kbuild new file +10
-0+/* + * our inode flags + */ +#define OBJ_2BCREATED 0 /* object will be created soon*/ +#define OBJ_CREATED 1 /* object has been created on the osd*/ + +static inline int obj_2bcreated(struct exofs_i_info *oi) +{ + return test_bit(OBJ_2BCREATED, &(oi->i_flags)); +}unneeded parentheses around
oi->i_flags.
Quoted 20 lines
Quoted 4 lines
fs/exofs/Kbuild new file +4
-0+static inline void set_obj_2bcreated(struct exofs_i_info *oi) +{ + set_bit(OBJ_2BCREATED, &(oi->i_flags)); +}fs/exofs/Kbuild
Quoted 10 lines
fs/exofs/Kbuild new file +10
-0+ +static inline int obj_created(struct exofs_i_info *oi) +{ + return test_bit(OBJ_CREATED, &(oi->i_flags)); +} + +static inline void set_obj_created(struct exofs_i_info *oi) +{ + set_bit(OBJ_CREATED, &(oi->i_flags)); +}dittoes.
Quoted 2 lines
...
Thanks
will fix
Boaz
PATCH 2/8 exofs: file and file_inode operations
In reply to Boaz Harroshimplementation of the file_operations and inode_operations for regular data files.
Most file_operations are generic vfs implementations except:
- exofs_truncate will truncate the OSD object as well
- Generic file_fsync is not good for none_bd devices so open code it
- The default for .flush in Linux is todo nothing so call exofs_fsync on the file.
--- fs/exofs/Kbuild | 2 +- fs/exofs/exofs.h | 14 +++++ fs/exofs/file.c | 82 ++++++++++++++++++++++++++++++ fs/exofs/inode.c | 148 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 245 insertions(+), 1 deletions(-) create mode 100644 fs/exofs/file.c create mode 100644 fs/exofs/inode.c
fs/exofs/Kbuild +1 -1
@@ -26,5 +26,5 @@ KBUILD_CPPFLAGS := -I$(OSD_INC) $(KBUILD_CPPFLAGS) endif -exofs-y := osd.o +exofs-y := osd.o inode.o file.o obj-$(CONFIG_EXOFS_FS) += exofs.o
fs/exofs/exofs.h +14 -0
@@ -124,4 +124,18 @@ static inline struct exofs_i_info *exofs_i(struct inode *inode) return container_of(inode, struct exofs_i_info, vfs_inode); } +/************************* +* function declarations * +*************************/ +/* inode.c */ +void exofs_truncate (struct inode *inode); +int exofs_setattr (struct dentry *,struct iattr *); + +/********************* +* operation vectors * +*********************/ +/* file.c */ +extern const struct inode_operations exofs_file_inode_operations; +extern const struct file_operations exofs_file_operations; +#endif
fs/exofs/file.c new file +82 -0
82 lines not on this page · raw message
fs/exofs/inode.c new file +148 -0
148 lines not on this page · raw message
Signature · 1 line
1.6.2.1
Re: [PATCH 2/8] exofs: file and file_inode operations
Quoted 13 lines · On Wed, 18 Mar 2009 19:58:47 +0200 Boaz Harrosh <[email protected]> wrote:
implementation of the
file_operationsandinode_operationsfor regular data files.Most
file_operationsare generic vfs implementations except:
-exofs_truncatewill truncate the OSD object as well
- Genericfile_fsyncis not good fornone_bddevices so open code it
- The default for .flush in Linux is todo nothing so callexofs_fsyncon the file....
fs/exofs/file.c new file +1
-0+static int exofs_file_fsync(struct file *filp, struct dentry *dentry,
fs/exofs/file.c line 55
Quoted 10 lines
fs/exofs/file.c new file +10
-0+ int datasync) +{ +int ret1, ret2; +struct address_space *mapping = filp->f_mapping; + + ret1 =filemap_write_and_wait (mapping); + ret2 =file_fsync (filp, dentry, datasync); + +return ret1 ? ret1 : ret2; +}
It might be better to abort if filemap_write_and_wait() failed. if the hardware is bad, these things can take a looooong time retrying and timing out. There's no point in doubling the delay.
Quoted 3 lines
...
Re: [PATCH 2/8] exofs: file and file_inode operations
Quoted 14 lines · Andrew Morton
Quoted 12 lines · On Wed, 18 Mar 2009 19:58:47 +0200 Boaz Harrosh <[email protected]> wrote:
implementation of the
file_operationsandinode_operationsfor regular data files.Most
file_operationsare generic vfs implementations except:
-exofs_truncatewill truncate the OSD object as well
- Genericfile_fsyncis not good fornone_bddevices so open code it
- The default for .flush in Linux is todo nothing so callexofs_fsyncon the file....
Quoted 19 lines
fs/exofs/file.c line 55
Quoted 11 lines
fs/exofs/file.c new file +11
-0+static int exofs_file_fsync (struct file *filp,struct dentry *dentry, +int datasync) +{ +int ret1, ret2; +struct address_space *mapping = filp->f_mapping; + + ret1 =filemap_write_and_wait (mapping); + ret2 =file_fsync (filp, dentry, datasync); + +return ret1 ? ret1 : ret2; +}It might be better to abort if
filemap_write_and_wait()failed. if the hardware is bad, these things can take a looooong time retrying and timing out. There's no point in doubling the delay.Quoted 2 lines
...
OK I got confused by existing code, good point
Boaz
PATCH 3/8 exofs: symlink_inode and fast_symlink_inode operations
In reply to Boaz HarroshGeneric implementation of symlink ops.
--- fs/exofs/Kbuild | 2 +- fs/exofs/exofs.h | 4 +++ fs/exofs/symlink.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 62 insertions(+), 1 deletions(-) create mode 100644 fs/exofs/symlink.c
fs/exofs/Kbuild +1 -1
@@ -26,5 +26,5 @@ KBUILD_CPPFLAGS := -I$(OSD_INC) $(KBUILD_CPPFLAGS) endif -exofs-y := osd.o inode.o file.o +exofs-y := osd.o inode.o file.o symlink.o obj-$(CONFIG_EXOFS_FS) += exofs.o
fs/exofs/exofs.h +4 -0
@@ -138,4 +138,8 @@ int exofs_setattr(struct dentry *, struct iattr *);extern const struct inode_operations exofs_file_inode_operations;extern const struct file_operations exofs_file_operations; +/* symlink.c */ +extern const struct inode_operations exofs_symlink_inode_operations; +extern const struct inode_operations exofs_fast_symlink_inode_operations; +#endif
fs/exofs/symlink.c new file +57 -0
57 lines not on this page · raw message
Signature · 1 line
1.6.2.1
PATCH 4/8 exofs: address_space_operations
In reply to Boaz HarroshOK Now we start to read and write from osd-objects. We try to collect at most contiguous pages as possible in a single write/read. The first page index is the object's offset.
TODO:
In 64-bit a single bio can carry at most 128 pages. Add support of chaining multiple bios
--- fs/exofs/exofs.h | 6 + fs/exofs/inode.c | 690 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 696 insertions(+), 0 deletions(-)
fs/exofs/exofs.h +6 -0
@@ -130,6 +130,9 @@ static inline struct exofs_i_info *exofs_i(struct inode *inode)/* inode.c */ void exofs_truncate (struct inode *inode);int exofs_setattr (struct dentry *,struct iattr *); +int exofs_write_begin (struct file *file,struct address_space *mapping, +loff_t pos,unsigned len,unsigned flags, +struct page **pagep,void **fsdata);/********************* * operation vectors *
@@ -138,6 +141,9 @@ int exofs_setattr(struct dentry *, struct iattr *);extern const struct inode_operations exofs_file_inode_operations;extern const struct file_operations exofs_file_operations; +/* inode.c */ +extern const struct address_space_operations exofs_aops; +/* symlink.c */ extern const struct inode_operations exofs_symlink_inode_operations;extern const struct inode_operations exofs_fast_symlink_inode_operations;
fs/exofs/inode.c +690 -0
702 lines not on this page · raw message
Signature · 1 line
1.6.2.1
Re: [PATCH 4/8] exofs: address_space_operations
Quoted 14 lines · Boaz Harrosh
(...)
fs/exofs/inode.c +12
-0+struct page_collect { +struct exofs_sb_info *sbi; +struct request_queue *req_q; +struct inode *inode; +unsigned expected_pages; + +struct bio *bio; +unsigned nr_pages; +unsigned long length; +long pg_first; +}; +int pcol_try_alloc (struct page_collect *pcol)
fs/exofs/inode.c line 106
Quoted 10 lines
fs/exofs/inode.c +10
-0+{ +int pages =min_t (unsigned, pcol->expected_pages,BIO_MAX_PAGES ); + +for (; pages; pages >>=1 ) { + pcol->bio =bio_alloc (GFP_KERNEL , pages); +if (likely (pcol->bio)) +return 0 ; + } + + EXOFS_ERR("Failed to kcalloc expected_pages=%d\n",
%u
Quoted 13 lines
fs/exofs/inode.c +12
-0+ pcol->expected_pages); +return -ENOMEM ; +} + +static int __readpages_done (struct osd_request *or,struct page_collect *pcol, +bool do_unlock) +{ +struct bio_vec *bvec; +int i; +u64 resid; +u64 good_bytes; +u64 length =0 ;
fs/exofs/inode.c line 181
Quoted 10 lines
fs/exofs/inode.c +10
-0+int ret =exofs_check_ok_resid (or, &resid,NULL ); + +osd_end_request (or); + +if (!ret) + good_bytes = pcol->length; +else if (ret && !resid) + good_bytes =0 ; +else + good_bytes = pcol->length - resid;
Second ret check is not needed.
Review
Quoted 3 lines
(...)
(quoted diff) +2
-0+ +int read_exec(struct page_collect *pcol, bool is_sync)
read_exec is too generic name for globally visible symbol
Quoted 12 lines
fs/exofs/inode.c +11
-0+{ +static void writepages_done (struct osd_request *or,void *p) +{ +struct page_collect *pcol = p; +struct bio_vec *bvec; +int i; +u64 resid; +u64 good_bytes; +u64 length =0 ; + +int ret =exofs_check_ok_resid (or,NULL , &resid);
fs/exofs/inode.c line 458
Quoted 10 lines
fs/exofs/inode.c +10
-0+ +osd_end_request (or); +atomic_dec (&pcol->sbi->s_curr_pending); + +if (likely (!ret)) + good_bytes = pcol->length; +else if (ret && !resid) + good_bytes =0 ; +else + good_bytes = pcol->length - resid;
Ret check again.
fs/exofs/inode.c line 496
Quoted 3 lines
(...)
fs/exofs/inode.c +2
-0+ +int write_exec (struct page_collect *pcol)
Too generic name.
Quoted 1 line
(...)
Re: [PATCH 4/8] exofs: address_space_operations
Quoted 85 lines · Marcin Slusarz
Quoted 14 lines · Boaz Harrosh
(...)
fs/exofs/inode.c +12
-0+struct page_collect { +struct exofs_sb_info *sbi; +struct request_queue *req_q; +struct inode *inode; +unsigned expected_pages; + +struct bio *bio; +unsigned nr_pages; +unsigned long length; +long pg_first; +}; +int pcol_try_alloc (struct page_collect *pcol)fs/exofs/inode.c line 106
Quoted 10 lines
fs/exofs/inode.c +10
-0+{ +int pages =min_t (unsigned, pcol->expected_pages,BIO_MAX_PAGES ); + +for (; pages; pages >>=1 ) { + pcol->bio =bio_alloc (GFP_KERNEL , pages); +if (likely (pcol->bio)) +return 0 ; + } + + EXOFS_ERR("Failed to kcalloc expected_pages=%d\n",%u
Quoted 13 lines
fs/exofs/inode.c +12
-0+ pcol->expected_pages); +return -ENOMEM ; +} + +static int __readpages_done (struct osd_request *or,struct page_collect *pcol, +bool do_unlock) +{ +struct bio_vec *bvec; +int i; +u64 resid; +u64 good_bytes; +u64 length =0 ;fs/exofs/inode.c line 181
Quoted 10 lines
fs/exofs/inode.c +10
-0+int ret =exofs_check_ok_resid (or, &resid,NULL ); + +osd_end_request (or); + +if (!ret) + good_bytes = pcol->length; +else if (ret && !resid) + good_bytes =0 ; +else + good_bytes = pcol->length - resid;Second ret check is not needed.
Review
Quoted 3 lines
(...)
(quoted diff) +2
-0+ +int read_exec(struct page_collect *pcol, bool is_sync)
read_execis too generic name for globally visible symbolQuoted 12 lines
fs/exofs/inode.c +11
-0+{ +static void writepages_done (struct osd_request *or,void *p) +{ +struct page_collect *pcol = p; +struct bio_vec *bvec; +int i; +u64 resid; +u64 good_bytes; +u64 length =0 ; + +int ret =exofs_check_ok_resid (or,NULL , &resid);fs/exofs/inode.c line 458
Quoted 10 lines
fs/exofs/inode.c +10
-0+ +osd_end_request (or); +atomic_dec (&pcol->sbi->s_curr_pending); + +if (likely (!ret)) + good_bytes = pcol->length; +else if (ret && !resid) + good_bytes =0 ; +else + good_bytes = pcol->length - resid;Ret check again.
Quoted 8 lines
fs/exofs/inode.c line 496
Quoted 3 lines
(...)
fs/exofs/inode.c +2
-0+ +int write_exec (struct page_collect *pcol)Too generic name.
Quoted 1 line
(...)
Right on all accounts. Thanks
will repost
Boaz
PATCH 4/8 exofs: address_space_operations
In reply to Boaz HarroshOK Now we start to read and write from osd-objects. We try to collect at most contiguous pages as possible in a single write/read. The first page index is the object's offset.
TODO:
In 64-bit a single bio can carry at most 128 pages. Add support of chaining multiple bios
--- fs/exofs/exofs.h | 6 + fs/exofs/inode.c | 691 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 697 insertions(+), 0 deletions(-)
fs/exofs/exofs.h +6 -0
@@ -130,6 +130,9 @@ static inline struct exofs_i_info *exofs_i(struct inode *inode)/* inode.c */ void exofs_truncate (struct inode *inode);int exofs_setattr (struct dentry *,struct iattr *); +int exofs_write_begin (struct file *file,struct address_space *mapping, +loff_t pos,unsigned len,unsigned flags, +struct page **pagep,void **fsdata);/********************* * operation vectors *
@@ -138,6 +141,9 @@ int exofs_setattr(struct dentry *, struct iattr *);extern const struct inode_operations exofs_file_inode_operations;extern const struct file_operations exofs_file_operations; +/* inode.c */ +extern const struct address_space_operations exofs_aops; +/* symlink.c */ extern const struct inode_operations exofs_symlink_inode_operations;extern const struct inode_operations exofs_fast_symlink_inode_operations;
fs/exofs/inode.c +691 -0
703 lines not on this page · raw message
Signature · 1 line
1.6.2.1
Re: [PATCH 4/8 ver5] exofs: address_space_operations
Quoted 12 lines · On Sun, 22 Mar 2009 15:58:46 +0200 Boaz Harrosh <[email protected]> wrote:
OK Now we start to read and write from osd-objects. We try to collect at most contiguous pages as possible in a single write/read. The first page index is the object's offset.
TODO:
In 64-bit a single bio can carry at most 128 pages. Add support of chaining multiple bios...
fs/exofs/inode.c line 504
Quoted 8 lines
fs/exofs/inode.c +8
-0+static int write_exec (struct page_collect *pcol) +{ +struct exofs_i_info *oi =exofs_i (pcol->inode); +struct osd_obj_id obj = {pcol->sbi->s_pid, + pcol->inode->i_ino +EXOFS_OBJ_OFF }; +struct osd_request *or =NULL ; +struct page_collect *pcol_copy =NULL ; +loff_t i_start = pcol->pg_first <<PAGE_CACHE_SHIFT ;
bug. On 32-bit this shift will overflow prior to getting promoted to 64-bit. Do:
loff_t i_start = (loff_t)pcol->pg_first << PAGE_CACHE_SHIFT;
fs/exofs/inode.c line 550
Quoted 5 lines
...
fs/exofs/inode.c +2
-0+static int writepage_strip (struct page *page, +struct writeback_control *wbc_unused,void *data)
Some of these functions could do with some comments explaining why they exist.
Quoted 11 lines
fs/exofs/inode.c +8
-0+struct page_collect *pcol = data; +struct inode *inode = pcol->inode; +struct exofs_i_info *oi =exofs_i (inode); +loff_t i_size =i_size_read (inode); +pgoff_t end_index = i_size >>PAGE_CACHE_SHIFT ; +size_t len; +int ret; +
Re: [PATCH 4/8 ver5] exofs: address_space_operations
Quoted 25 lines · Andrew Morton
Quoted 11 lines · On Sun, 22 Mar 2009 15:58:46 +0200 Boaz Harrosh <[email protected]> wrote:
OK Now we start to read and write from osd-objects. We try to collect at most contiguous pages as possible in a single write/read. The first page index is the object's offset.
TODO:
In 64-bit a single bio can carry at most 128 pages. Add support of chaining multiple bios...
fs/exofs/inode.c line 504
Quoted 8 lines
fs/exofs/inode.c +8
-0+static int write_exec (struct page_collect *pcol) +{ +struct exofs_i_info *oi =exofs_i (pcol->inode); +struct osd_obj_id obj = {pcol->sbi->s_pid, + pcol->inode->i_ino +EXOFS_OBJ_OFF }; +struct osd_request *or =NULL ; +struct page_collect *pcol_copy =NULL ; +loff_t i_start = pcol->pg_first <<PAGE_CACHE_SHIFT ;bug. On 32-bit this shift will overflow prior to getting promoted to 64-bit. Do:
Quoted 2 lines
loff_t i_start = (loff_t)pcol->pg_first << PAGE_CACHE_SHIFT;
In that case I might make pcol->pg_first loff_t.
Why is inode->i_index not an loff_t then?
Page-index <=> byte-offset, is done all the time 12 bits does not make a difference.
Quoted 16 lines
fs/exofs/inode.c line 550
Quoted 4 lines
...
fs/exofs/inode.c +2
-0+static int writepage_strip (struct page *page, +struct writeback_control *wbc_unused,void *data)Some of these functions could do with some comments explaining why they exist.
Quoted 9 lines
fs/exofs/inode.c +8
-0+struct page_collect *pcol = data; +struct inode *inode = pcol->inode; +struct exofs_i_info *oi =exofs_i (inode); +loff_t i_size =i_size_read (inode); +pgoff_t end_index = i_size >>PAGE_CACHE_SHIFT ; +size_t len; +int ret; +
Quoted 3 lines
Quoted 2 lines
...
Thanks
Boaz
Re: [PATCH 4/8 ver5] exofs: address_space_operations
Quoted 12 lines · On Tue, 31 Mar 2009 12:04:36 +0300 Boaz Harrosh <[email protected]> wrote:
Quoted 12 lines
fs/exofs/inode.c line 504
Quoted 8 lines
fs/exofs/inode.c +8
-0+static int write_exec (struct page_collect *pcol) +{ +struct exofs_i_info *oi =exofs_i (pcol->inode); +struct osd_obj_id obj = {pcol->sbi->s_pid, + pcol->inode->i_ino +EXOFS_OBJ_OFF }; +struct osd_request *or =NULL ; +struct page_collect *pcol_copy =NULL ; +loff_t i_start = pcol->pg_first <<PAGE_CACHE_SHIFT ;bug. On 32-bit this shift will overflow prior to getting promoted to 64-bit. Do:
Quoted 4 lines
Quoted 2 lines
loff_t i_start = (loff_t)pcol->pg_first << PAGE_CACHE_SHIFT;In that case I might make
pcol->pg_firstloff_t.
That would work.
Quoted 1 line
Why is
inode->i_indexnot anloff_tthen?
hm, what's i_index?
Quoted 2 lines
Page-index <=> byte-offset, is done all the time 12 bits does not make a difference.
Page indices are 32-bit on 32-bit CPUs. File offsets are 64-bit. We are careful to avoid the above overflow bug whenever the conversion from page index to file size is made. Try
fgrep '(loff_t)' mm/*.c
Re: [PATCH 4/8 ver5] exofs: address_space_operations
Quoted 15 lines · Andrew Morton
Quoted 13 lines · On Tue, 31 Mar 2009 12:04:36 +0300 Boaz Harrosh <[email protected]> wrote:
Quoted 13 lines
fs/exofs/inode.c line 504
Quoted 8 lines
fs/exofs/inode.c +8
-0+static int write_exec (struct page_collect *pcol) +{ +struct exofs_i_info *oi =exofs_i (pcol->inode); +struct osd_obj_id obj = {pcol->sbi->s_pid, + pcol->inode->i_ino +EXOFS_OBJ_OFF }; +struct osd_request *or =NULL ; +struct page_collect *pcol_copy =NULL ; +loff_t i_start = pcol->pg_first <<PAGE_CACHE_SHIFT ;bug. On 32-bit this shift will overflow prior to getting promoted to 64-bit. Do:
loff_t i_start = (loff_t)pcol->pg_first << PAGE_CACHE_SHIFT;
Quoted 8 lines
Quoted 1 line
In that case I might make
pcol->pg_firstloff_t.That would work.
Quoted 1 line
Why is
inode->i_indexnot anloff_tthen?hm, what's
i_index?
sorry, I meant page index
Quoted 9 lines
Quoted 2 lines
Page-index <=> byte-offset, is done all the time 12 bits does not make a difference.
Page indices are 32-bit on 32-bit CPUs. File offsets are 64-bit. We are careful to avoid the above overflow bug whenever the conversion from page index to file size is made. Try
fgrep '(loff_t)' mm/*.c
right! which means that Linux does not support 64 bit offsets on 32 bit, but only 44 bits. But I guess exofs will not change that.
Boaz
PATCH 5/8 exofs: dir_inode and directory operations
In reply to Boaz Harroshimplementation of directory and inode operations.
* A directory is treated as a file, and essentially contains a list of <file name, inode #> pairs for files that are found in that directory. The object IDs correspond to the files' inode numbers and are allocated using a 64bit incrementing global counter.
* Each file's control block (AKA on-disk inode) is stored in its object's attributes. This applies to both regular files and other types (directories, device files, symlinks, etc.).
--- fs/exofs/Kbuild | 2 +- fs/exofs/dir.c | 656 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/exofs/exofs.h | 26 +++ fs/exofs/inode.c | 272 ++++++++++++++++++++++ fs/exofs/namei.c | 342 ++++++++++++++++++++++++++++ 5 files changed, 1297 insertions(+), 1 deletions(-) create mode 100644 fs/exofs/dir.c create mode 100644 fs/exofs/namei.c
fs/exofs/Kbuild +1 -1
@@ -26,5 +26,5 @@ KBUILD_CPPFLAGS := -I$(OSD_INC) $(KBUILD_CPPFLAGS) endif -exofs-y := osd.o inode.o file.o symlink.o +exofs-y := osd.o inode.o file.o symlink.o namei.o dir.o obj-$(CONFIG_EXOFS_FS) += exofs.o
fs/exofs/dir.c new file +656 -0
656 lines not on this page · raw message
fs/exofs/exofs.h +26 -0
@@ -124,6 +124,11 @@ static inline struct exofs_i_info *exofs_i(struct inode *inode) return container_of(inode, struct exofs_i_info, vfs_inode); } +/* +* Maximum count of links to a file +*/ +#define EXOFS_LINK_MAX 32000 +/************************* * function declarations * *************************/
@@ -133,10 +138,27 @@ int exofs_setattr(struct dentry *, struct iattr *);int exofs_write_begin (struct file *file,struct address_space *mapping,loff_t pos,unsigned len,unsigned flags,struct page **pagep,void **fsdata); +extern struct inode *exofs_iget (struct super_block *,unsigned long ); +struct inode *exofs_new_inode (struct inode *,int ); + +/* dir.c: */ +int exofs_add_link (struct dentry *,struct inode *); +ino_t exofs_inode_by_name (struct inode *,struct dentry *); +int exofs_delete_entry (struct exofs_dir_entry *,struct page *); +int exofs_make_empty (struct inode *,struct inode *); +struct exofs_dir_entry *exofs_find_entry (struct inode *,struct dentry *, +struct page **); +int exofs_empty_dir (struct inode *); +struct exofs_dir_entry *exofs_dotdot (struct inode *,struct page **); +int exofs_set_link (struct inode *,struct exofs_dir_entry *,struct page *, +struct inode *);/********************* * operation vectors * *********************/ +/* dir.c: */ +extern const struct file_operations exofs_dir_operations; +/* file.c */ extern const struct inode_operations exofs_file_inode_operations;extern const struct file_operations exofs_file_operations;
@@ -144,6 +166,10 @@ extern const struct file_operations exofs_file_operations;/* inode.c */ extern const struct address_space_operations exofs_aops; +/* namei.c */ +extern const struct inode_operations exofs_dir_inode_operations; +extern const struct inode_operations exofs_special_inode_operations; +/* symlink.c */ extern const struct inode_operations exofs_symlink_inode_operations;extern const struct inode_operations exofs_fast_symlink_inode_operations;
fs/exofs/inode.c +272 -0
275 lines not on this page · raw message
fs/exofs/namei.c new file +342 -0
342 lines not on this page · raw message
Signature · 1 line
1.6.2.1
Re: [PATCH 5/8] exofs: dir_inode and directory operations
Quoted 13 lines · On Wed, 18 Mar 2009 20:08:49 +0200 Boaz Harrosh <[email protected]> wrote:
implementation of directory and inode operations.
* A directory is treated as a file, and essentially contains a list of <file name, inode #> pairs for files that are found in that directory. The object IDs correspond to the files' inode numbers and are allocated using a 64bit incrementing global counter.
* Each file's control block (AKA on-disk inode) is stored in its object's attributes. This applies to both regular files and other types (directories, device files, symlinks, etc.)....
fs/exofs/dir.c line 52
Quoted 4 lines
fs/exofs/dir.c new file +4
-0+static inline unsigned long dir_pages (struct inode *inode) +{ +return (inode->i_size +PAGE_CACHE_SIZE -1 ) >>PAGE_CACHE_SHIFT ; +}
Do we need i_size_read() here? Probably not if it's always called under i_mutex. Needs checking and commenting please.
fs/exofs/dir.c line 58
Quoted 5 lines
fs/exofs/dir.c new file +5
-0+static unsigned exofs_last_byte (struct inode *inode,unsigned long page_nr) +{ +unsigned last_byte = inode->i_size; + + last_byte -= page_nr <<PAGE_CACHE_SHIFT ;
hm. Strange to left-shift an unsigned long and then copy it to a smaller type.
Are the types here appropriately chosen?
fs/exofs/dir.c
Quoted 9 lines
fs/exofs/dir.c new file +6
-0+if (last_byte >PAGE_CACHE_SIZE ) + last_byte =PAGE_CACHE_SIZE ; +return last_byte; +} + +static int exofs_commit_chunk (struct page *page,loff_t pos,unsigned len)
This all looks vaguely familiar :)
Re: [PATCH 5/8] exofs: dir_inode and directory operations
Quoted 15 lines · Andrew Morton
Quoted 13 lines · On Wed, 18 Mar 2009 20:08:49 +0200 Boaz Harrosh <[email protected]> wrote:
implementation of directory and inode operations.
* A directory is treated as a file, and essentially contains a list of <file name, inode #> pairs for files that are found in that directory. The object IDs correspond to the files' inode numbers and are allocated using a 64bit incrementing global counter.
* Each file's control block (AKA on-disk inode) is stored in its object's attributes. This applies to both regular files and other types (directories, device files, symlinks, etc.)....
Quoted 8 lines
fs/exofs/dir.c line 52
Quoted 4 lines
fs/exofs/dir.c new file +4
-0+static inline unsigned long dir_pages (struct inode *inode) +{ +return (inode->i_size +PAGE_CACHE_SIZE -1 ) >>PAGE_CACHE_SHIFT ; +}Do we need
i_size_read()here? Probably not if it's always called underi_mutex. Needs checking and commenting please.
Don't know, I'll have a look
Quoted 9 lines
fs/exofs/dir.c line 58
Quoted 5 lines
fs/exofs/dir.c new file +5
-0+static unsigned exofs_last_byte (struct inode *inode,unsigned long page_nr) +{ +unsigned last_byte = inode->i_size; + + last_byte -= page_nr <<PAGE_CACHE_SHIFT ;hm. Strange to left-shift an unsigned long and then copy it to a smaller type.
wrong type, thanks!
Quoted 9 lines
Are the types here appropriately chosen?
Quoted 7 lines
fs/exofs/dir.c new file +6
-0+if (last_byte >PAGE_CACHE_SIZE ) + last_byte =PAGE_CACHE_SIZE ; +return last_byte; +} + +static int exofs_commit_chunk (struct page *page,loff_t pos,unsigned len)
Quoted 4 lines
Quoted 2 lines
...
This all looks vaguely familiar :)
Yep ;). Don't forget that all this started with a cp ...
Boaz
PATCH 6/8 exofs: super_operations and file_system_type
In reply to Boaz HarroshThis patch ties all operation vectors into a file system superblock and registers the exofs file_system_type at module's load time.
* The file system control block (AKA on-disk superblock) resides in an object with a special ID (defined in common.h). Information included in the file system control block is used to fill the in-memory superblock structure at mount time. This object is created before the file system is used by mkexofs.c It contains information such as:
- The file system's magic number
- The next inode number to be allocated
--- fs/exofs/Kbuild | 2 +- fs/exofs/exofs.h | 22 +++ fs/exofs/inode.c | 188 ++++++++++++++++++++ fs/exofs/super.c | 520 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 731 insertions(+), 1 deletions(-) create mode 100644 fs/exofs/super.c
fs/exofs/Kbuild +1 -1
@@ -26,5 +26,5 @@ KBUILD_CPPFLAGS := -I$(OSD_INC) $(KBUILD_CPPFLAGS) endif -exofs-y := osd.o inode.o file.o symlink.o namei.o dir.o +exofs-y := osd.o inode.o file.o symlink.o namei.o dir.o super.o obj-$(CONFIG_EXOFS_FS) += exofs.o
fs/exofs/exofs.h +22 -0
@@ -54,6 +54,15 @@#define _LLU (x) (unsigned long long)(x)/* +* struct to hold what we get from mount options +*/ +struct exofs_mountopt { +const char *dev_name; +uint64_t pid; +int timeout; +}; + +/* * our extension to the in-memory superblock */ struct exofs_sb_info {
@@ -125,6 +134,14 @@ static inline struct exofs_i_info *exofs_i(struct inode *inode) }/* +* ugly struct so that we can pass two arguments to update_inode's callback +*/ +struct updatei_args { +struct exofs_sb_info *sbi; +struct exofs_fcb fcb; +}; + +/* * Maximum count of links to a file */ #define EXOFS_LINK_MAX 32000
@@ -140,6 +157,8 @@ int exofs_write_begin(struct file *file, struct address_space *mapping, struct page **pagep, void **fsdata);extern struct inode *exofs_iget (struct super_block *,unsigned long );struct inode *exofs_new_inode (struct inode *,int ); +extern int exofs_write_inode (struct inode *,int ); +extern void exofs_delete_inode (struct inode *);/* dir.c: */ int exofs_add_link (struct dentry *,struct inode *);
@@ -170,6 +189,9 @@ extern const struct address_space_operations exofs_aops;extern const struct inode_operations exofs_dir_inode_operations;extern const struct inode_operations exofs_special_inode_operations; +/* super.c */ +extern const struct super_operations exofs_sops; +/* symlink.c */ extern const struct inode_operations exofs_symlink_inode_operations;extern const struct inode_operations exofs_fast_symlink_inode_operations;
fs/exofs/inode.c +188 -0
191 lines not on this page · raw message
fs/exofs/super.c new file +520 -0
520 lines not on this page · raw message
Signature · 1 line
1.6.2.1
Re: [PATCH 6/8] exofs: super_operations and file_system_type
Quoted 18 lines · On Wed, 18 Mar 2009 20:09:51 +0200 Boaz Harrosh <[email protected]> wrote:
This patch ties all operation vectors into a file system superblock and registers the exofs
file_system_typeat module's load time.* The file system control block (AKA on-disk superblock) resides in an object with a special ID (defined in
common.h). Information included in the file system control block is used to fill the in-memory superblock structure at mount time. This object is created before the file system is used bymkexofs.cIt contains information such as:
- The file system's magic number
- The next inode number to be allocated...
fs/exofs/super.c new file +3
-0+static int exofs_statfs (struct dentry *dentry,struct kstatfs *buf) +{ +struct super_block *sb = dentry->d_sb;
fs/exofs/super.c line 419
Quoted 10 lines
fs/exofs/super.c new file +10
-0+struct exofs_sb_info *sbi = sb->s_fs_info; +struct osd_obj_id obj = {sbi->s_pid,0 }; +struct osd_attr attrs[] = { +ATTR_DEF (OSD_APAGE_PARTITION_QUOTAS , +OSD_ATTR_PQ_CAPACITY_QUOTA ,sizeof (__be64)), +ATTR_DEF (OSD_APAGE_PARTITION_INFORMATION , +OSD_ATTR_PI_USED_CAPACITY ,sizeof (__be64)), + }; +uint64_t capacity = ~0 ; +uint64_t used = ~0 ;
My brain hurts.
~0 is signed 0xffffffff.
When assigning to a u64 it gets signed extended to signed 0xffffffffffffffff and then converted to unsigned 0xffffffffffffffff.
I think. Just as with plain old "-1". Perhaps using plain old "-1" would be clearer here.
Quoted 4 lines
...
+const struct
super_operationsexofs_sops= {
This can in fact be made static, I believe.
Quoted 3 lines
...
Re: [PATCH 6/8] exofs: super_operations and file_system_type
Quoted 38 lines · Andrew Morton
Quoted 18 lines · On Wed, 18 Mar 2009 20:09:51 +0200 Boaz Harrosh <[email protected]> wrote:
This patch ties all operation vectors into a file system superblock and registers the exofs
file_system_typeat module's load time.* The file system control block (AKA on-disk superblock) resides in an object with a special ID (defined in
common.h). Information included in the file system control block is used to fill the in-memory superblock structure at mount time. This object is created before the file system is used bymkexofs.cIt contains information such as:
- The file system's magic number
- The next inode number to be allocated...
fs/exofs/super.c new file +3
-0+static int exofs_statfs (struct dentry *dentry,struct kstatfs *buf) +{ +struct super_block *sb = dentry->d_sb;fs/exofs/super.c line 419
Quoted 10 lines
fs/exofs/super.c new file +10
-0+struct exofs_sb_info *sbi = sb->s_fs_info; +struct osd_obj_id obj = {sbi->s_pid,0 }; +struct osd_attr attrs[] = { +ATTR_DEF (OSD_APAGE_PARTITION_QUOTAS , +OSD_ATTR_PQ_CAPACITY_QUOTA ,sizeof (__be64)), +ATTR_DEF (OSD_APAGE_PARTITION_INFORMATION , +OSD_ATTR_PI_USED_CAPACITY ,sizeof (__be64)), + }; +uint64_t capacity = ~0 ; +uint64_t used = ~0 ;My brain hurts.
~0 is signed
0xffffffff.When assigning to a u64 it gets signed extended to signed
0xffffffffffffffffand then converted to unsigned0xffffffffffffffff.
Quoted 12 lines
I think. Just as with plain old "-1". Perhaps using plain old "-1" would be clearer here.
Quoted 3 lines
...
+const struct
super_operationsexofs_sops= {This can in fact be made static, I believe.
Quoted 2 lines
...
OK, OK.
Thanks will fix
Boaz
Re: [osd-dev] [PATCH 6/8] exofs: super_operations and file_system_type
In reply to Andrew MortonQuoted 33 lines · Andrew Morton
Quoted 18 lines · On Wed, 18 Mar 2009 20:09:51 +0200 Boaz Harrosh <[email protected]> wrote:
This patch ties all operation vectors into a file system superblock and registers the exofs
file_system_typeat module's load time.* The file system control block (AKA on-disk superblock) resides in an object with a special ID (defined in
common.h). Information included in the file system control block is used to fill the in-memory superblock structure at mount time. This object is created before the file system is used bymkexofs.cIt contains information such as:
- The file system's magic number
- The next inode number to be allocated...
fs/exofs/super.c new file +3
-0+static int exofs_statfs (struct dentry *dentry,struct kstatfs *buf) +{ +struct super_block *sb = dentry->d_sb;fs/exofs/super.c line 419
Quoted 10 lines
fs/exofs/super.c new file +10
-0+struct exofs_sb_info *sbi = sb->s_fs_info; +struct osd_obj_id obj = {sbi->s_pid,0 }; +struct osd_attr attrs[] = { +ATTR_DEF (OSD_APAGE_PARTITION_QUOTAS , +OSD_ATTR_PQ_CAPACITY_QUOTA ,sizeof (__be64)), +ATTR_DEF (OSD_APAGE_PARTITION_INFORMATION , +OSD_ATTR_PI_USED_CAPACITY ,sizeof (__be64)), + }; +uint64_t capacity = ~0 ; +uint64_t used = ~0 ;My brain hurts.
Quoted 4 lines
~0 is signed
0xffffffff.When assigning to a u64 it gets signed extended to signed
0xffffffffffffffffand then converted to unsigned0xffffffffffffffff.
Right (I think, I'm not sure in what order)
Quoted 3 lines
I think. Just as with plain old "-1". Perhaps using plain old "-1" would be clearer here.
or maybe ~0ULL or ~(uint64_t)0 to be extremely anal about it.
Benny
Quoted 14 lines
Quoted 4 lines
...
+const struct
super_operationsexofs_sops= {This can in fact be made static, I believe.
Quoted 2 lines
...
_______________________________________________
osd-dev mailing list
[email protected]
http://mailman.open-osd.org/mailman/listinfo/osd-dev
Re: [osd-dev] [PATCH 6/8] exofs: super_operations and file_system_type
Quoted 6 lines · Benny Halevy
Quoted 4 lines · Andrew Morton
~0 is signed
0xffffffff.When assigning to a u64 it gets signed extended to signed
0xffffffffffffffffand then converted to unsigned0xffffffffffffffff.
Quoted 9 lines
Right (I think, I'm not sure in what order)
Quoted 2 lines
I think. Just as with plain old "-1". Perhaps using plain old "-1" would be clearer here.
or maybe ~0ULL or ~(uint64_t)0 to be extremely anal about it.
Benny
There is only one right way => ULLONG_MAX. Takes care of the human factor too. (BTW that one is defined (~0ULL))
Thanks
Boaz
Re: [osd-dev] [PATCH 6/8] exofs: super_operations and file_system_type
Quoted 10 lines · Boaz Harrosh
Quoted 9 lines · Benny Halevy
Quoted 4 lines · Andrew Morton
~0 is signed
0xffffffff.When assigning to a u64 it gets signed extended to signed
0xffffffffffffffffand then converted to unsigned0xffffffffffffffff.Right (I think, I'm not sure in what order)
Quoted 2 lines
I think. Just as with plain old "-1". Perhaps using plain old "-1" would be clearer here.
Quoted 7 lines
Quoted 4 lines
or maybe ~0ULL or ~(uint64_t)0 to be extremely anal about it.
Benny
There is only one right way =>
ULLONG_MAX. Takes care of the human factor too. (BTW that one is defined (~0ULL))
Ideally, since the variable is a uint64_t, you'd want a U64_MAX. unsigned long long may, at some point, be larger than uint64 on some architectures. With the available defs ~(uint64_t)0 or even just ~0 seem more portable...
Benny
Quoted 4 lines
Thanks
Boaz
PATCH 7/8 exofs: Documentation
In reply to Boaz HarroshAdded some documentation in exofs.txt, as well as a BUGS file.
For further reading, operation instructions, example scripts and up to date infomation and code please see:
http://open-osd.org
--- Documentation/filesystems/exofs.txt | 176 +++++++++++++++++++++++++++++++++++ fs/exofs/BUGS | 3 + 2 files changed, 179 insertions(+), 0 deletions(-) create mode 100644 Documentation/filesystems/exofs.txt create mode 100644 fs/exofs/BUGS
Documentation/filesystems/exofs.txt new file +176 -0
@@ -0,0 +1,176 @@ +=============================================================================== +WHAT IS EXOFS? +=============================================================================== + +exofs is a file system that uses an OSD and exports the API of a normal Linux +file system. Users access exofs like any other local file system, and exofs +will in turn issue commands to the local OSD initiator. + +OSD is a new T10 command set that views storage devices not as a large/flat +array of sectors but as a container of objects, each having a length, quota, +time attributes and more. Each object is addressed by a 64bit ID, and is +contained in a 64bit ID partition. Each object has associated attributes +attached to it, which are integral part of the object and provide metadata about +the object. The standard defines some common obligatory attributes, but user +attributes can be added as needed. + +=============================================================================== +ENVIRONMENT +=============================================================================== + +To use this file system, you need to have an object store to run it on. You +may download a target from: +http://open-osd.org + +See Documentation/scsi/osd.txt for how to setup a working osd environment. + +=============================================================================== +USAGE +=============================================================================== + +1. Download and compile exofs and open-osd initiator: + You need an external Kernel source tree or kernel headers from your + distribution. (anything based on 2.6.26 or later). + + a. download open-osd including exofs source using: + [parent-directory]$ git clone git://git.open-osd.org/open-osd.git + + b. Build the library module like this: + [parent-directory]$ make -C KSRC=$(KER_DIR) open-osd + + This will build both the open-osd initiator as well as the exofs kernel + module. Use whatever parameters you compiled your Kernel with and + $(KER_DIR) above pointing to the Kernel you compile against. See the file + open-osd/top-level-Makefile for an example. + +2. Get the OSD initiator and target set up properly, and login to the target. + See Documentation/scsi/osd.txt for farther instructions. Also see ./do-osd + for example script that does all these steps. + +3. Insmod the exofs.ko module: + [exofs]$ insmod exofs.ko + +4. Make sure the directory where you want to mount exists. If not, create it. + (For example, mkdir /mnt/exofs) + +5. At first run you will need to invoke the mkfs.exofs application + + As an example, this will create the file system on: + /dev/osd0 partition ID 65536 + + mkfs.exofs --pid=65536 --format /dev/osd0 + + The --format is optional if not specified no OSD_FORMAT will be + preformed and a clean file system will be created in the specified pid, + in the available space of the target. (Use --format=size_in_meg to limit + the total LUN space available) + + If pid already exist it will be deleted and a new one will be created in it's + place. Be careful. + + An exofs lives inside a single OSD partition. You can create multiple exofs + filesystems on the same device using multiple pids. + + (run mkfs.exofs without any parameters for usage help message) + +6. Mount the file system. + + For example, to mount /dev/osd0, partition ID 0x10000 on /mnt/exofs: + + mount -t exofs -o pid=65536 /dev/osd0 /mnt/exofs/ + +7. For reference (See do-exofs example script): + do-exofs start - an example of how to perform the above steps. + do-exofs stop - an example of how to unmount the file system. + do-exofs format - an example of how to format and mkfs a new exofs. + +8. Extra compilation flags (uncomment in fs/exofs/Kbuild): + CONFIG_EXOFS_DEBUG - for debug messages and extra checks. + +=============================================================================== +exofs mount options +=============================================================================== +Similar to any mount command: + mount -t exofs -o exofs_options /dev/osdX mount_exofs_directory + +Where: + -t exofs: specifies the exofs file system + + /dev/osdX: X is a decimal number. /dev/osdX was created after a successful + login into an OSD target. + + mount_exofs_directory: The directory to mount the file system on + + exofs specific options: Options are separated by commas (,) + pid=<integer> - The partition number to mount/create as + container of the filesystem. + This option is mandatory + to=<integer> - Timeout in ticks for a single command + default is (60 * HZ) [for debugging only] + +=============================================================================== +DESIGN +=============================================================================== + +* The file system control block (AKA on-disk superblock) resides in an object + with a special ID (defined in common.h). + Information included in the file system control block is used to fill the + in-memory superblock structure at mount time. This object is created before + the file system is used by mkexofs.c It contains information such as: + - The file system's magic number + - The next inode number to be allocated + +* Each file resides in its own object and contains the data (and it will be + possible to extend the file over multiple objects, though this has not been + implemented yet). + +* A directory is treated as a file, and essentially contains a list of <file + name, inode #> pairs for files that are found in that directory. The object + IDs correspond to the files' inode numbers and will be allocated according to + a bitmap (stored in a separate object). Now they are allocated using a + counter. + +* Each file's control block (AKA on-disk inode) is stored in its object's + attributes. This applies to both regular files and other types (directories, + device files, symlinks, etc.). + +* Credentials are generated per object (inode and superblock) when they is + created in memory (read off disk or created). The credential works for all + operations and is used as long as the object remains in memory. + +* Async OSD operations are used whenever possible, but the target may execute + them out of order. The operations that concern us are create, delete, + readpage, writepage, update_inode, and truncate. The following pairs of + operations should execute in the order written, and we need to prevent them + from executing in reverse order: + - The following are handled with the OBJ_CREATED and OBJ_2BCREATED + flags. OBJ_CREATED is set when we know the object exists on the OSD - + in create's callback function, and when we successfully do a read_inode. + OBJ_2BCREATED is set in the beginning of the create function, so we + know that we should wait. + - create/delete: delete should wait until the object is created + on the OSD. + - create/readpage: readpage should be able to return a page + full of zeroes in this case. If there was a write already + en-route (i.e. create, writepage, readpage) then the page + would be locked, and so it would really be the same as + create/writepage. + - create/writepage: if writepage is called for a sync write, it + should wait until the object is created on the OSD. + Otherwise, it should just return. + - create/truncate: truncate should wait until the object is + created on the OSD. + - create/update_inode: update_inode should wait until the + object is created on the OSD. + - Handled by VFS locks: + - readpage/delete: shouldn't happen because of page lock. + - writepage/delete: shouldn't happen because of page lock. + - readpage/writepage: shouldn't happen because of page lock. + +=============================================================================== +LICENSE/COPYRIGHT +=============================================================================== +The exofs file system is based on ext2 v0.5b (distributed with the Linux kernel +version 2.6.10). All files include the original copyrights, and the license +is GPL version 2 (only version 2, as is true for the Linux kernel). The +Linux kernel can be downloaded from www.kernel.org.
fs/exofs/BUGS new file +3 -0
@@ -0,0 +1,3 @@ +- Out-of-space may cause a severe problem if the object (and directory entry) + were written, but the inode attributes failed. Then if the filesystem was + unmounted and mounted the kernel can get into an endless loop doing a readdir.
Signature · 1 line
1.6.2.1
Re: [PATCH 7/8] exofs: Documentation
Hi.
fs/exofs/BUGS line 3
Quoted 5 lines · Boaz Harrosh
+++ b/fs/exofs/BUGS
fs/exofs/BUGS new file +3
-0@@ -0,0 +1,3 @@ +- Out-of-space may cause a severe problem if the object (and directory entry) + were written, but the inode attributes failed. Then if the filesystem was + unmounted and mounted the kernel can get into an endless loop doing a readdir.
Does it also mean that damaged media may end up freezing the machine during the mount?
Signature · 1 line
Evgeniy Polyakov
Re: [PATCH 7/8] exofs: Documentation
Quoted 12 lines · Evgeniy Polyakov
Hi.
fs/exofs/BUGS line 3
Quoted 5 lines · Boaz Harrosh
+++ b/fs/exofs/BUGS
fs/exofs/BUGS new file +3
-0@@ -0,0 +1,3 @@ +- Out-of-space may cause a severe problem if the object (and directory entry) + were written, but the inode attributes failed. Then if the filesystem was + unmounted and mounted the kernel can get into an endless loop doing a readdir.Does it also mean that damaged media may end up freezing the machine during the mount?
I had such situation and it was able to mount. Some data was lost.
But sure, if the damage was in a way like above it would. The bad situation is when there is a directory entry, there is a corresponding object, but there is an error reading the associated attribute. the redir code does not expect to fail, independent from iget()
It is difficult for me to repeat this problem because I've changed the osd-target I'm running with, and with the new target attributes are stored an a DB, so the create-object fails with ENOSP long before I'm no longer able to write attributes. But I'm sure one day this problem will come to hunt me.
Thanks
Boaz
PATCH 8/8 fs: Add exofs to Kernel build
In reply to Boaz Harrosh- Add exofs to fs/Kconfig under "menu 'Miscellaneous filesystems'"
- Add exofs to fs/Makefile
--- fs/Kconfig | 2 ++ fs/Makefile | 1 + 2 files changed, 3 insertions(+), 0 deletions(-)
fs/Kconfig +2 -0
@@ -223,6 +223,8 @@ source "fs/romfs/Kconfig" source "fs/sysv/Kconfig" source "fs/ufs/Kconfig" +source "fs/exofs/Kconfig" + endif # MISC_FILESYSTEMS menuconfig NETWORK_FILESYSTEMS
fs/Makefile +1 -0
@@ -124,3 +124,4 @@ obj-$(CONFIG_DEBUG_FS) += debugfs/ obj-$(CONFIG_OCFS2_FS) += ocfs2/ obj-$(CONFIG_BTRFS_FS) += btrfs/ obj-$(CONFIG_GFS2_FS) += gfs2/ +obj-$(CONFIG_EXOFS_FS) += exofs/
Signature · 1 line
1.6.2.1
PATCH 8/8 fs: Add exofs to Kernel build
In reply to Boaz Harrosh- Add exofs to fs/Kconfig under "menu 'Miscellaneous filesystems'"
- Add exofs to fs/Makefile
--- fs/Kconfig | 2 ++ fs/Makefile | 1 + 2 files changed, 3 insertions(+), 0 deletions(-)
fs/Kconfig +2 -0
@@ -223,6 +223,8 @@ source "fs/romfs/Kconfig" source "fs/sysv/Kconfig" source "fs/ufs/Kconfig" +source "fs/exofs/Kconfig" + endif # MISC_FILESYSTEMS menuconfig NETWORK_FILESYSTEMS
fs/Makefile +1 -0
@@ -124,3 +124,4 @@ obj-$(CONFIG_DEBUG_FS) += debugfs/ obj-$(CONFIG_OCFS2_FS) += ocfs2/ obj-$(CONFIG_BTRFS_FS) += btrfs/ obj-$(CONFIG_GFS2_FS) += gfs2/ +obj-$(CONFIG_EXOFS_FS) += exofs/
Signature · 1 line
1.6.2.1
Quoted 21 lines · Boaz Harrosh
What's new since last iteration:
* I completely re-wrote the [PATCH 4/8] exofs:
address_space_operationsin which we actually write/read to/from osd-storage. The difference is that now we try to accumulate as many contiguous pages as possible and send them as one large request. As opposed to writing each page at a time, in the previous patchset.* [PATCH 5/8] exofs:
dir_inodeand directory operations received lots of love thanks to Evgeniy Polyakov's grate comments.exofs is a file system that uses an OSD device as it's back store.
OSD is a new T10 command set that views storage devices not as a large/flat array of sectors but as a container of objects, each having a length, quota, time attributes and more. Each object is addressed by a 64bit ID, and is contained in a 64bit ID partition. Each object has associated attributes attached to it, which are integral part of the object and provide metadata about the object. The standard defines some common obligatory attributes, but user attributes can be added as needed.
Quoted 2 lines
Here is the list of patches
[PATCH 1/8] exofs:Kbuild, Headers and osd utils
I have updated this patch on git.open-osd.org
Kbuild fallout
Quoted 3 lines
[PATCH 2/8] exofs: file and
file_inodeoperations [PATCH 3/8] exofs:symlink_inodeandfast_symlink_inodeoperations [PATCH 4/8] exofs:address_space_operations
I have posted a new version of this patch
Quoted 2 lines
[PATCH 5/8] exofs:
dir_inodeand directory operations [PATCH 6/8] exofs:super_operationsandfile_system_type
Minor clean-up to this patch
(moved local structures to c file from header, remove unused function)
Quoted 3 lines
[PATCH 7/8] exofs: Documentation
[PATCH 8/8] fs: Add exofs to Kernel build
Revised patchset can be found on link below
Attached the total diff from last HEAD
Quoted 13 lines
This patchset is also available on:
git-clonegit://git.open-osd.org/linux-open-osd.gitlinux-next
or on the web at:
http://git.open-osd.org/gitweb.cgi?p=linux-open-osd.git;a=shortlog;h=refs/heads/linux-next(Above tree is based on Linus v2.6.29-rc8-212-g8144737)
If anyone wants to actually run this code and test it then please start reading at:
http://open-osd.orgYou will need to checkout the out-of-tree git (below) for the user-mode utilities. Also the exofs.txt file in patch 7/8 should help
Quoted 7 lines
If you want to review the user-mode library and supporting plumbings,
git-clonegit://git.open-osd.org/open-osd.git
or on the web at:
http://git.open-osd.org/gitweb.cgi?p=open-osd.git;a=summaryBoaz
Thanks
Boaz
git diff --stat -p 690dd5e9e739cb0c66a792c5d7949f6e97113427..linux-next -- fs/exofs/
fs/exofs/Kbuild | 2 +- fs/exofs/exofs.h | 17 ----------------- fs/exofs/file.c | 4 ++++ fs/exofs/inode.c | 45 ++++++++++++++++++++++----------------------- fs/exofs/super.c | 9 +++++++++ 5 files changed, 36 insertions(+), 41 deletions(-)
fs/exofs/Kbuild +1 -1
@@ -22,7 +22,7 @@ ccflags-y += -DCONFIG_EXOFS_FS -DCONFIG_EXOFS_FS_MODULE # if we are built out-of-tree and the hosting kernel has OSD headers # then "ccflags-y +=" will not pick the out-off-tree headers. Only by doing # this it will work. This might break in future kernels -KBUILD_CPPFLAGS := -I$(OSD_INC) $(KBUILD_CPPFLAGS) +LINUXINCLUDE := -I$(OSD_INC) $(LINUXINCLUDE) endif
fs/exofs/exofs.h +0 -17
@@ -54,15 +54,6 @@#define _LLU (x) (unsigned long long)(x)/* -* struct to hold what we get from mount options -*/ -struct exofs_mountopt { -const char *dev_name; -uint64_t pid; -int timeout; -}; - -/* * our extension to the in-memory superblock */ struct exofs_sb_info {
@@ -134,14 +125,6 @@ static inline struct exofs_i_info *exofs_i(struct inode *inode) }/* -* ugly struct so that we can pass two arguments to update_inode's callback -*/ -struct updatei_args { -struct exofs_sb_info *sbi; -struct exofs_fcb fcb; -}; - -/* * Maximum count of links to a file */ #define EXOFS_LINK_MAX 32000
fs/exofs/file.c +4 -0
@@ -49,6 +49,10 @@ static int exofs_file_fsync(struct file *filp, struct dentry *dentry,struct address_space *mapping = filp->f_mapping; ret1 =filemap_write_and_wait (mapping); +/*Note: file_fsync below also calles sync_blockdev, which is a no-op +* for exofs, but other then that it does sync_inode and +* sync_superblock which is what we need here. +*/ ret2 =file_fsync (filp, dentry, datasync);return ret1 ? ret1 : ret2;
fs/exofs/inode.c +22 -23
127 lines not on this page · raw message
fs/exofs/super.c +9 -0
@@ -45,6 +45,15 @@*****************************************************************************/ /* +* struct to hold what we get from mount options +*/ +struct exofs_mountopt { +const char *dev_name; +uint64_t pid; +int timeout; +}; + +/* * exofs-specific mount-time options. */ enum { Opt_pid, Opt_to, Opt_mkfs, Opt_format, Opt_err };
Quoted 44 lines · Boaz Harrosh
What's new since last iteration:
* I completely re-wrote the [PATCH 4/8] exofs:
address_space_operationsin which we actually write/read to/from osd-storage. The difference is that now we try to accumulate as many contiguous pages as possible and send them as one large request. As opposed to writing each page at a time, in the previous patchset.* [PATCH 5/8] exofs:
dir_inodeand directory operations received lots of love thanks to Evgeniy Polyakov's grate comments.exofs is a file system that uses an OSD device as it's back store.
OSD is a new T10 command set that views storage devices not as a large/flat array of sectors but as a container of objects, each having a length, quota, time attributes and more. Each object is addressed by a 64bit ID, and is contained in a 64bit ID partition. Each object has associated attributes attached to it, which are integral part of the object and provide metadata about the object. The standard defines some common obligatory attributes, but user attributes can be added as needed.
Here is the list of patches
[PATCH 1/8] exofs:Kbuild, Headers and osd utils
[PATCH 2/8] exofs: file andfile_inodeoperations [PATCH 3/8] exofs:symlink_inodeandfast_symlink_inodeoperations [PATCH 4/8] exofs:address_space_operations
[PATCH 5/8] exofs:dir_inodeand directory operations [PATCH 6/8] exofs:super_operationsandfile_system_type[PATCH 7/8] exofs: Documentation
[PATCH 8/8] fs: Add exofs to Kernel buildThis patchset is also available on:
git-clonegit://git.open-osd.org/linux-open-osd.gitlinux-next
or on the web at:
http://git.open-osd.org/gitweb.cgi?p=linux-open-osd.git;a=shortlog;h=refs/heads/linux-next(Above tree is based on Linus v2.6.29-rc8-212-g8144737)
If anyone wants to actually run this code and test it then please start reading at:
http://open-osd.orgYou will need to checkout the out-of-tree git (below) for the user-mode utilities. Also the exofs.txt file in patch 7/8 should help
Quoted 7 lines
If you want to review the user-mode library and supporting plumbings,
git-clonegit://git.open-osd.org/open-osd.git
or on the web at:
http://git.open-osd.org/gitweb.cgi?p=open-osd.git;a=summaryBoaz
Hi Linus
In the matter of above new exofs file system.
Andrew Morton has suggested that you might prefer to directly pull form the open-osd git-tree instead of him pushing it through his tree?
The exofs tree will be pushed only at second stage of the merge window as it is dependent on patches to the osd-initiator which sit in James's scsi-misc tree.
I'm monitoring the [email protected] mailing list and once I see all dependent patches are in main-line I'll send you a pull request, or Andrew which ever you prefer?
Some background ml thread:
http://www.spinics.net/lists/linux-scsi/msg32104.html
The code was sitting in linux-next since 2.6.29-rc1. It is Kconfigured off by default and it will only impacted osd early adaptors/developers.
Thank you very much in advance
Boaz Harrosh
Quoted 21 lines · On Wed, 18 Mar 2009 19:45:01 +0200 Boaz Harrosh <[email protected]> wrote:
What's new since last iteration:
* I completely re-wrote the [PATCH 4/8] exofs:
address_space_operationsin which we actually write/read to/from osd-storage. The difference is that now we try to accumulate as many contiguous pages as possible and send them as one large request. As opposed to writing each page at a time, in the previous patchset.* [PATCH 5/8] exofs:
dir_inodeand directory operations received lots of love thanks to Evgeniy Polyakov's grate comments.exofs is a file system that uses an OSD device as it's back store.
OSD is a new T10 command set that views storage devices not as a large/flat array of sectors but as a container of objects, each having a length, quota, time attributes and more. Each object is addressed by a 64bit ID, and is contained in a 64bit ID partition. Each object has associated attributes attached to it, which are integral part of the object and provide metadata about the object. The standard defines some common obligatory attributes, but user attributes can be added as needed.
Quoted 9 lines
Here is the list of patches
[PATCH 1/8] exofs:Kbuild, Headers and osd utils
[PATCH 2/8] exofs: file andfile_inodeoperations [PATCH 3/8] exofs:symlink_inodeandfast_symlink_inodeoperations [PATCH 4/8] exofs:address_space_operations
[PATCH 5/8] exofs:dir_inodeand directory operations [PATCH 6/8] exofs:super_operationsandfile_system_type[PATCH 7/8] exofs: Documentation
[PATCH 8/8] fs: Add exofs to Kernel build
Are all the prerequisites for exofs now in mainline?
Quoted 4 lines
This patchset is also available on:
git-clonegit://git.open-osd.org/linux-open-osd.gitlinux-next
or on the web at:
http://git.open-osd.org/gitweb.cgi?p=linux-open-osd.git;a=shortlog;h=refs/heads/linux-next
Well I could merge them, but given that you have a git tree, a more convenient path would be for us to include your tree in linux-next and then you ask Linus to pull it directly when the time comes.
I'm unsure when that time will come. Who has reviewed this work and what was the result?
Quoted 9 lines · On Mon, 30 Mar 2009 14:22:00 -0700 Andrew Morton <[email protected]>…
Quoted 5 lines
This patchset is also available on:
git-clonegit://git.open-osd.org/linux-open-osd.gitlinux-next
or on the web at:
http://git.open-osd.org/gitweb.cgi?p=linux-open-osd.git;a=shortlog;h=refs/heads/linux-nextWell I could merge them, but given that you have a git tree, a more convenient path would be for us to include your tree in linux-next and then you ask Linus to pull it directly when the time comes.
$ git cat-file -p next-20090330:Next/Trees | grep osd osd git git://git.open-osd.org/linux-open-osd.git#linux-next
i.e. its in there. Those particular patches have been in linux-next since next-20090326 and presumably have been built by the all{yes,mod}config builds I do.
Quoted 2 lines
I'm unsure when that time will come. Who has reviewed this work and what was the result?
That is a good question. The other is "Is this destined for 2.6.30?"
Signature · 3 lines
Cheers, Stephen Rothwell [email protected] http://www.canb.auug.org.au/~sfr/
Hi.
Quoted 4 lines · Stephen Rothwell
Quoted 2 lines
I'm unsure when that time will come. Who has reviewed this work and what was the result?
That is a good question. The other is "Is this destined for 2.6.30?"
There was a lengthy discussion in scsi list.
I made another review of the previous revision and we talked a bit about ducumented features/bugs for the current one.
Signature · 1 line
Evgeniy Polyakov
Quoted 34 lines · Andrew Morton
Quoted 21 lines · On Wed, 18 Mar 2009 19:45:01 +0200 Boaz Harrosh <[email protected]> wrote:
What's new since last iteration:
* I completely re-wrote the [PATCH 4/8] exofs:
address_space_operationsin which we actually write/read to/from osd-storage. The difference is that now we try to accumulate as many contiguous pages as possible and send them as one large request. As opposed to writing each page at a time, in the previous patchset.* [PATCH 5/8] exofs:
dir_inodeand directory operations received lots of love thanks to Evgeniy Polyakov's grate comments.exofs is a file system that uses an OSD device as it's back store.
OSD is a new T10 command set that views storage devices not as a large/flat array of sectors but as a container of objects, each having a length, quota, time attributes and more. Each object is addressed by a 64bit ID, and is contained in a 64bit ID partition. Each object has associated attributes attached to it, which are integral part of the object and provide metadata about the object. The standard defines some common obligatory attributes, but user attributes can be added as needed.
Quoted 9 lines
Here is the list of patches
[PATCH 1/8] exofs:Kbuild, Headers and osd utils
[PATCH 2/8] exofs: file andfile_inodeoperations [PATCH 3/8] exofs:symlink_inodeandfast_symlink_inodeoperations [PATCH 4/8] exofs:address_space_operations
[PATCH 5/8] exofs:dir_inodeand directory operations [PATCH 6/8] exofs:super_operationsandfile_system_type[PATCH 7/8] exofs: Documentation
[PATCH 8/8] fs: Add exofs to Kernel build
Quoted 2 lines
Are all the prerequisites for exofs now in mainline?
Yes they are all in
Quoted 7 lines
Quoted 4 lines
This patchset is also available on:
git-clonegit://git.open-osd.org/linux-open-osd.gitlinux-next
or on the web at:
http://git.open-osd.org/gitweb.cgi?p=linux-open-osd.git;a=shortlog;h=refs/heads/linux-nextWell I could merge them, but given that you have a git tree, a more convenient path would be for us to include your tree in linux-next
As Stephan said they are there since 2.6.29-rc1
Quoted 3 lines
and
then you ask Linus to pull it directly when the time comes.
I was hoping the time is now
Quoted 4 lines
I'm unsure when that time will come. Who has reviewed this work and what was the result?
The patches have been reveiwed on linux-kernel and linux-fsdevel for 5-6 rounds. Each round drew it's comments which I fixed and so on.
The code is pretty well as far as styling and layout. And I'm not sure what else can be done for them.
As far as quality robustness and performance, that's hard to say since it has not been used outside of the labs yet. Perhaps being in mainline will give the exposure it needs to stabilize.
Exofs is the only current candidate user for the osd in mainline, and in a shape that does things relatively well as far as we could test it.
It has lots of work still to do on it in order to make it the pNFS-Objects filesystem it needs to be. One reason it is very important for me that it will go in mainline is because of the pNFS patches that need to come. pNFS is an out-of-tree staging area that holds the up coming pNFS stuff that will be added to Linux. It currently holds patches that will eventually go through 4 different git trees / maintainers. if exofs is left outside it is another headache added. And of course is the hassle of keeping out-of-tree code for another round, that's depressing. I don't see what is the danger of inclusion and what is to be gained with keeping this out-of-tree? Please advise you have much longer experience with these thing then me.
For long term plans By next kernel exofs should be pNFS capable, and a pNFS-object-layout driver should be added for the pNFS client side. The layout driver is based on the same infrastructure as exofs. Then farther down exofs will need to be multi-device raids and all.
Lots of more work to do, but first thing first, can this be included in 2.6.30?
Thanks
Boaz
Quoted 54 lines · Boaz Harrosh
Quoted 33 lines · Andrew Morton
Quoted 21 lines · On Wed, 18 Mar 2009 19:45:01 +0200 Boaz Harrosh <[email protected]> wrote:
What's new since last iteration:
* I completely re-wrote the [PATCH 4/8] exofs:
address_space_operationsin which we actually write/read to/from osd-storage. The difference is that now we try to accumulate as many contiguous pages as possible and send them as one large request. As opposed to writing each page at a time, in the previous patchset.* [PATCH 5/8] exofs:
dir_inodeand directory operations received lots of love thanks to Evgeniy Polyakov's grate comments.exofs is a file system that uses an OSD device as it's back store.
OSD is a new T10 command set that views storage devices not as a large/flat array of sectors but as a container of objects, each having a length, quota, time attributes and more. Each object is addressed by a 64bit ID, and is contained in a 64bit ID partition. Each object has associated attributes attached to it, which are integral part of the object and provide metadata about the object. The standard defines some common obligatory attributes, but user attributes can be added as needed.
Quoted 9 lines
Here is the list of patches
[PATCH 1/8] exofs:Kbuild, Headers and osd utils
[PATCH 2/8] exofs: file andfile_inodeoperations [PATCH 3/8] exofs:symlink_inodeandfast_symlink_inodeoperations [PATCH 4/8] exofs:address_space_operations
[PATCH 5/8] exofs:dir_inodeand directory operations [PATCH 6/8] exofs:super_operationsandfile_system_type[PATCH 7/8] exofs: Documentation
[PATCH 8/8] fs: Add exofs to Kernel buildQuoted 2 lines
Are all the prerequisites for exofs now in mainline?
Yes they are all in
Quoted 6 lines
Quoted 4 lines
This patchset is also available on:
git-clonegit://git.open-osd.org/linux-open-osd.gitlinux-next
or on the web at:
http://git.open-osd.org/gitweb.cgi?p=linux-open-osd.git;a=shortlog;h=refs/heads/linux-nextWell I could merge them, but given that you have a git tree, a more convenient path would be for us to include your tree in linux-next
As Stephan said they are there since 2.6.29-rc1
Quoted 3 lines
and
then you ask Linus to pull it directly when the time comes.I was hoping the time is now
Quoted 8 lines
Quoted 4 lines
I'm unsure when that time will come. Who has reviewed this work and what was the result?
The patches have been reveiwed on linux-kernel and linux-fsdevel for 5-6 rounds. Each round drew it's comments which I fixed and so on.
I forgot to say. Some of the people that sent comments where:
Marcin Slusarz <[email protected]>
Evgeniy Polyakov <[email protected]>
Jeff Garzik <[email protected]>
Pavel Machek <[email protected]>
Benny Halevy <[email protected]>
Alan Cox <[email protected]>
Andrew Morton <[email protected]>
And then there was a long flame war about user-mode API, which I now have, and all in kernel utilities are gone.
To the best of my knowledge I have addressed all comments, at least no one complained.
<snip>
Thanks
Boaz
Quoted 10 lines · On Tue, 31 Mar 2009 10:41:29 +0300 Boaz Harrosh <[email protected]> wrote:
I forgot to say. Some of the people that sent comments where:
Marcin Slusarz <[email protected]>
Evgeniy Polyakov <[email protected]>
Jeff Garzik <[email protected]>
Pavel Machek <[email protected]>
Benny Halevy <[email protected]>
Alan Cox <[email protected]>
Andrew Morton <[email protected]>
Quoted 6 lines
And then there was a long flame war about user-mode API, which I now have, and all in kernel utilities are gone.
To the best of my knowledge I have addressed all comments, at least no one complained.
Let me take a quick look...
<quickly looks>
OK, I foud a few minor things, but the code looks fine to me. However I cannot speak to the overall design and to the actual desirability of adding the feature to Linux.
I'd say that unless someone pipes up with a showstopper objection in the next few days, please send the pull request to Linus near the end of the week.
Quoted 5 lines · Boaz Harrosh
If anyone wants to actually run this code and test it then please start reading at:
http://open-osd.orgYou will need to checkout the out-of-tree git (below) for the user-mode utilities. Also the exofs.txt file in patch 7/8 should help
hum... trying to play with this. If you want exofs to go upstream, I think you should have a release tarball containing the user-mode utils posted somewhere. Would make life a lot easier, both on early adopters and also on distribution packagers.
Jeff
Quoted 8 lines · Jeff Garzik
Quoted 5 lines · Boaz Harrosh
If anyone wants to actually run this code and test it then please start reading at:
http://open-osd.orgYou will need to checkout the out-of-tree git (below) for the user-mode utilities. Also the exofs.txt file in patch 7/8 should help
Quoted 6 lines
hum... trying to play with this. If you want exofs to go upstream, I think you should have a release tarball containing the user-mode utils posted somewhere. Would make life a lot easier, both on early adopters and also on distribution packagers.
Jeff
You are absolutely right, once 2.6.30 will be out there will not be a need to compile Kernel modules.
About the binary package. I must admit I'm a total novice. What do I need to do?
One x86_32, one x86_64? What glibc, does it matter what distro I compile on?
I want to have a "make rpm" and "make deb" but I've never done that, I was hoping someone more experienced would pick it up.
But you are right I have it on my schedule to work on the Wiki, installation and init-scripts, right after this final push to mainline.
Sorry, for not having this already
Boaz
BTW:
Source tar balls are available from the gitweb GUI by pressing on the "snapshot" link next to any commit. I should link to it from the WiKi
Best regards
Boaz
Quoted 8 lines · Boaz Harrosh
Quoted 7 lines · Jeff Garzik
Quoted 5 lines · Boaz Harrosh
If anyone wants to actually run this code and test it then please start reading at:
http://open-osd.orgYou will need to checkout the out-of-tree git (below) for the user-mode utilities. Also the exofs.txt file in patch 7/8 should help
Quoted 8 lines
Quoted 3 lines
hum... trying to play with this. If you want exofs to go upstream, I think you should have a release tarball containing the user-mode utils posted somewhere. Would make life a lot easier, both on early adopters and also on distribution packagers.
Jeff
You are absolutely right, once 2.6.30 will be out there will not be a need to compile Kernel modules.
About the binary package. I must admit I'm a total novice. What do I need to do?
All you need on your end is a sane setup for installation, including building of shared libraries and installing necessary headers for userland programs.
Each individual distribution can easily package your exofs-utils into a deb or RPM.
Some of my projects have to do this. Here is one way, the highly standardized GNU autotools.
Take a look at autogen.sh, configure.ac, Makefile.am, include/Makefile.am and lib/Makefile.am from git://git.kernel.org/pub/scm/daemon/distsrv/chunkd.git
That demonstrates how to handle building and installing a shared library, header files and programs.
A lot of people dislike GNU autotools, but it's main benefit here is that Debian/Red Hat/Novell/Canonical/etc. are well-versed in creating .deb or .rpm from GNU autotools builds. It makes integration into a Linux distribution much easier.
Quoted 3 lines
BTW:
Source tar balls are available from the gitweb GUI by pressing on the "snapshot" link next to any commit. I should link to it from the WiKi
Oh yeah, I forgot about that.
Jeff
Quoted 33 lines · Jeff Garzik
Quoted 12 lines · Boaz Harrosh
Quoted 11 lines · Jeff Garzik
Quoted 5 lines · Boaz Harrosh
If anyone wants to actually run this code and test it then please start reading at:
http://open-osd.orgYou will need to checkout the out-of-tree git (below) for the user-mode utilities. Also the exofs.txt file in patch 7/8 should help
hum... trying to play with this. If you want exofs to go upstream, I think you should have a release tarball containing the user-mode utils posted somewhere. Would make life a lot easier, both on early adopters and also on distribution packagers.
Quoted 5 lines
Quoted 1 line
Jeff
You are absolutely right, once 2.6.30 will be out there will not be a need to compile Kernel modules.
About the binary package. I must admit I'm a total novice. What do I need to do?
All you need on your end is a sane setup for installation, including building of shared libraries and installing necessary headers for userland programs.
Each individual distribution can easily package your exofs-utils into a deb or RPM.
Some of my projects have to do this. Here is one way, the highly standardized GNU autotools.
Take a look at
autogen.sh, configure.ac, Makefile.am,include/Makefile.amandlib/Makefile.amfromgit://git.kernel.org/pub/scm/daemon/distsrv/chunkd.git
Quoted 8 lines
That demonstrates how to handle building and installing a shared library, header files and programs.
A lot of people dislike GNU autotools, but it's main benefit here is that Debian/Red Hat/Novell/Canonical/etc. are well-versed in creating .deb or .rpm from GNU autotools builds. It makes integration into a Linux distribution much easier.
This is precious information for me, I'll have a look and copy above procedure for open-osd, thanks, Next beer is on me.
Quoted 9 lines
Quoted 4 lines
BTW:
Source tar balls are available from the gitweb GUI by pressing on the "snapshot" link next to any commit. I should link to it from the WiKiOh yeah, I forgot about that.
Jeff
Thank you
Boaz