11 May, 2015

1 commit


20 Oct, 2014

1 commit


21 May, 2012

1 commit

  • Introduce sysfs infrastructure for exofs cluster filesystem.

    Each OSD target shows up as below in the sysfs hierarchy:
    /sys/fs/exofs/_/devX

    Where _ is the unique identification
    of a Superblock.

    Where devX: 0 < device_table_size. They are ordered
    in device-table order as specified to the mkfs.exofs command

    Each OSD device devX has following attributes :
    osdname - ReadOnly
    systemid - ReadOnly
    uri - Read/Write

    It is up to user-mode to update devX/uri for support of
    autologin.

    These sysfs information are used both for autologin as well
    as support for exporting exofs via a pNFSD server in user-mode.
    (.eg NFS-Ganesha)

    Signed-off-by: Sachin Bhamare
    Signed-off-by: Boaz Harrosh

    Sachin Bhamare
     

25 Oct, 2011

1 commit

  • This patch introduces the first stage of RAID5 support
    mainly the skip-over-raid-units when reading. For
    writes it inserts BLANK units, into where XOR blocks
    should be calculated and written to.

    It introduces the new "general raid maths", and the main
    additional parameters and components needed for raid5.

    Since at this stage it could corrupt future version that
    actually do support raid5. The enablement of raid5
    mounting and setting of parity-count > 0 is disabled. So
    the raid5 code will never be used. Mounting of raid5 is
    only enabled later once the basic XOR write is also in.
    But if the patch "enable RAID5" is applied this code has
    been tested to be able to properly read raid5 volumes
    and is according to standard.

    Also it has been tested that the new maths still properly
    supports RAID0 and grouping code just as before.
    (BTW: I have found more bugs in the pnfs-obj RAID math
    fixed here)

    The ore.c file is getting too big, so new ore_raid.[hc]
    files are added that will include the special raid stuff
    that are not used in striping and mirrors. In future write
    support these will get bigger.
    When adding the ore_raid.c to Kbuild file I was forced to
    rename ore.ko to libore.ko. Is it possible to keep source
    file, say ore.c and module file ore.ko the same even if there
    are multiple files inside ore.ko?

    Signed-off-by: Boaz Harrosh

    Boaz Harrosh
     

07 Aug, 2011

2 commits

  • Export everything from ore need exporting. Change Kbuild and Kconfig
    to build ore.ko as an independent module. Import ore from exofs

    Signed-off-by: Boaz Harrosh

    Boaz Harrosh
     
  • ORE stands for "Objects Raid Engine"

    This patch is a mechanical rename of everything that was in ios.c
    and its API declaration to an ore.c and an osd_ore.h header. The ore
    engine will later be used by the pnfs objects layout driver.

    * File ios.c => ore.c

    * Declaration of types and API are moved from exofs.h to a new
    osd_ore.h

    * All used types are prefixed by ore_ from their exofs_ name.

    * Shift includes from exofs.h to osd_ore.h so osd_ore.h is
    independent, include it from exofs.h.

    Other than a pure rename there are no other changes. Next patch
    will move the ore into it's own module and will export the API
    to be used by exofs and later the layout driver

    Signed-off-by: Boaz Harrosh

    Boaz Harrosh
     

10 Dec, 2009

1 commit

  • If I do a "git mv" together with a massive code change
    and commit in one patch, git looses the rename and
    records a delete/new instead. This is bad because I want
    a rename recorded so later rebased/cherry-picked patches
    to the old name will work. Also the --follow is lost.

    Signed-off-by: Boaz Harrosh

    Boaz Harrosh
     

01 Apr, 2009

5 commits

  • This 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

    Signed-off-by: Boaz Harrosh

    Boaz Harrosh
     
  • implementation of directory and inode operations.

    * A directory is treated as a file, and essentially contains a list
    of 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.).

    Signed-off-by: Boaz Harrosh

    Boaz Harrosh
     
  • Generic implementation of symlink ops.

    Signed-off-by: Boaz Harrosh

    Boaz Harrosh
     
  • implementation 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.

    Signed-off-by: Boaz Harrosh

    Boaz Harrosh
     
  • 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.

    Signed-off-by: Boaz Harrosh

    Boaz Harrosh