06 Jan, 2012

1 commit

  • As Reported by Randy Dunlap

    When MISC_FILESYSTEMS is not enabled and NFS4.1 is:

    fs/built-in.o: In function `objio_alloc_io_state':
    objio_osd.c:(.text+0xcb525): undefined reference to `ore_get_rw_state'
    fs/built-in.o: In function `_write_done':
    objio_osd.c:(.text+0xcb58d): undefined reference to `ore_check_io'
    fs/built-in.o: In function `_read_done':
    ...

    When MISC_FILESYSTEMS, which is more of a GUI thing then anything else,
    is not selected. exofs/Kconfig is never examined during Kconfig,
    and it can not do it's magic stuff to automatically select everything
    needed.

    We must split exofs/Kconfig in two. The ore one is always included.
    And the exofs one is left in it's old place in the menu.

    [Needed for the 3.2.0 Kernel]
    CC: Stable Tree
    Reported-by: Randy Dunlap
    Signed-off-by: Boaz Harrosh

    Boaz Harrosh
     

03 Nov, 2011

1 commit

  • In this patch we are actually moving to the ORE.
    (Object Raid Engine).

    objio_state holds a pointer to an ore_io_state. Once
    we have an ore_io_state at hand we can call the ore
    for reading/writing. We register on the done path
    to kick off the nfs io_done mechanism.

    Again for Ease of reviewing the old code is "#if 0"
    but is not removed so the diff command works better.
    The old code will be removed in the next patch.

    fs/exofs/Kconfig::ORE is modified to also be auto-included
    if PNFS_OBJLAYOUT is set. Since we now depend on ORE.
    (See comments in fs/exofs/Kconfig)

    Signed-off-by: Boaz Harrosh
    Signed-off-by: Trond Myklebust

    Boaz Harrosh
     

25 Oct, 2011

1 commit

  • This is finally the RAID5 Write support.

    The bigger part of this patch is not the XOR engine itself, But the
    read4write logic, which is a complete mini prepare_for_striping
    reading engine that can read scattered pages of a stripe into cache
    so it can be used for XOR calculation. That is, if the write was not
    stripe aligned.

    The main algorithm behind the XOR engine is the 2 dimensional array:
    struct __stripe_pages_2d.
    A drawing might save 1000 words
    ---

    __stripe_pages_2d
    |
    n = pages_in_stripe_unit;
    w = group_width - parity;
    | pages array presented to the XOR lib
    | |
    V |
    __1_page_stripe[0].pages --> [c0][c1]..[cw][c_par] [c0][c1]..[cw][c_par] [c0][c1]..[cw][c_par]
    ^
    |
    data added columns first then row

    ---
    The pages are put on this array columns first. .i.e:
    p0-of-c0, p1-of-c0, ... pn-of-c0, p0-of-c1, ...
    So we are doing a corner turn of the pages.

    Note that pages will zigzag down and left. but are put sequentially
    in growing order. So when the time comes to XOR the stripe, only the
    beginning and end of the array need be checked. We scan the array
    and any NULL spot will be field by pages-to-be-read.

    The FS that wants to support RAID5 needs to supply an
    operations-vector that searches a given page in cache, and specifies
    if the page is uptodate or need reading. All these pages to be read
    are put on a slave ore_io_state and synchronously read. All the pages
    of a stripe are read in one IO, using the scatter gather mechanism.

    In write we constrain our IO to only be incomplete on a single
    stripe. Meaning either the complete IO is within a single stripe so
    we might have pages to read from both beginning or end of the
    strip. Or we have some reading to do at beginning but end at strip
    boundary. The left over pages are pushed to the next IO by the API
    already established by previous work, where an IO offset/length
    combination presented to the ORE might get the length truncated and
    the user must re-submit the leftover pages. (Both exofs and NFS
    support this)

    But any ORE user should make it's best effort to align it's IO
    before hand and avoid complications. A cached ore_layout->stripe_size
    member can be used for that calculation. (NOTE: that ORE demands
    that stripe_size may not be bigger then 32bit)

    What else? Well read it and tell me.

    Signed-off-by: Boaz Harrosh

    Boaz Harrosh
     

07 Aug, 2011

1 commit


01 Apr, 2009

1 commit

  • 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