09 Jul, 2011

1 commit

  • Pavol pointed out that there is one silent error case in the mount
    path, and that others are rather uninformative.

    I've taken Pavol's suggested patch and extended it a bit to also:

    * fix a message which says "turned off" but actually errors out
    * consolidate the vaguely differentiated "SB sanity check [12]"
    messages, and hexdump the superblock for analysis

    Original-patch-by: Pavol Gono
    Signed-off-by: Eric Sandeen
    Signed-off-by: Alex Elder

    Eric Sandeen
     

19 Oct, 2010

2 commits

  • This patch adds support for 32bit project quota identifiers.

    On disk format is backward compatible with 16bit projid numbers. projid
    on disk is now kept in two 16bit values - di_projid_lo (which holds the
    same position as old 16bit projid value) and new di_projid_hi (takes
    existing padding) and converts from/to 32bit value on the fly.

    xfs_admin (for existing fs), mkfs.xfs (for new fs) needs to be used
    to enable PROJID32BIT support.

    Signed-off-by: Arkadiusz Miśkiewicz
    Reviewed-by: Christoph Hellwig
    Signed-off-by: Alex Elder

    Arkadiusz Mi?kiewicz
     
  • XFS_IOC_ZERO_RANGE is the equivalent of an atomic XFS_IOC_UNRESVSP/
    XFS_IOC_RESVSP call pair. It enabled ranges of written data to be
    turned into zeroes without requiring IO or having to free and
    reallocate the extents in the range given as would occur if we had
    to punch and then preallocate them separately. This enables
    applications to zero parts of files very quickly without changing
    the layout of the files in any way.

    Signed-off-by: Dave Chinner
    Reviewed-by: Christoph Hellwig

    Dave Chinner
     

03 Sep, 2010

1 commit

  • In xfs_vn_fiemap, we set bvm_count to fi_extent_max + 1 and want
    to return fi_extent_max extents, but actually it won't work for
    a sparse file. The reason is that in xfs_getbmap we will
    calculate holes and set it in 'out', while out is malloced by
    bmv_count(fi_extent_max+1) which didn't consider holes. So in the
    worst case, if 'out' vector looks like
    [hole, extent, hole, extent, hole, ... hole, extent, hole],
    we will only return half of fi_extent_max extents.

    This patch add a new parameter BMV_IF_NO_HOLES for bvm_iflags.
    So with this flags, we don't use our 'out' in xfs_getbmap for
    a hole. The solution is a bit ugly by just don't increasing
    index of 'out' vector. I felt that it is not easy to skip it
    at the very beginning since we have the complicated check and
    some function like xfs_getbmapx_fix_eof_hole to adjust 'out'.

    Cc: Dave Chinner
    Signed-off-by: Tao Ma
    Signed-off-by: Alex Elder

    Tao Ma
     

06 Mar, 2010

1 commit

  • So that fsr can attempt to get the fork offset of the temporary
    inode it uses the same as the inode it is defragmenting, pass the
    fork offset out in the bulkstat information.

    The bulkstat structure has padding that has always been zeroed, so
    userspace can tell if this field is set or not by use of the xattr
    present flag and a non-zero value for the fork offset.

    Signed-off-by: Dave Chinner
    Reviewed-by: Christoph Hellwig
    Signed-off-by: Alex Elder

    Dave Chinner
     

21 Sep, 2009

1 commit


08 Jun, 2009

1 commit

  • Commit a6634fba3dec4a92f0a2c4e30c80b634c0576ad5 in xfsprogs increased the
    maximum log size supported by mkfs. Merged back the changes to xfs_fs.h
    so the growfs enforced the same limit and the headers are in sync.

    Signed-off-by: Christoph Hellwig
    Reviewed-by: Eric Sandeen

    Christoph Hellwig
     

10 Jan, 2009

1 commit


02 Dec, 2008

1 commit

  • This makes the c file less cluttered and a bit more
    readable. Consistently name the ioctl number
    macros with "_32" and the compatibility stuctures
    with "_compat." Rename the helpers which simply
    copy in the arg with "_copyin" for easy identification.

    Finally, for a few of the existing helpers, modify them
    so that they directly call the native ioctl helper
    after userspace argument fixup.

    Signed-off-by: Eric Sandeen
    Reviewed-by: Christoph Hellwig
    Signed-off-by: Lachlan McIlroy

    sandeen@sandeen.net
     

01 Dec, 2008

2 commits

  • This adds a new output flag, BMV_OF_LAST to indicate if we've hit
    the last extent in the inode. This potentially saves an extra call
    from userspace to see when the whole mapping is done.

    It also adds BMV_IF_DELALLOC and BMV_OF_DELALLOC to request, and
    indicate, delayed-allocation extents. In this case bmv_block
    is set to -2 (-1 was already taken for HOLESTARTBLOCK; unfortunately
    these are the reverse of the in-kernel constants.)

    These new flags facilitate addition of the new fiemap interface.

    Rather than adding sh_delalloc, remove sh_unwritten & just test
    the flags directly.

    Signed-off-by: Eric Sandeen
    Reviewed-by: Christoph Hellwig
    Signed-off-by: Niv Sardi

    Eric Sandeen
     
  • Preliminary work to hook up fiemap, this allows us to pass in an
    arbitrary formatter to copy extent data back to userspace.

    The formatter takes info for 1 extent, a pointer to the user "thing*"
    and a pointer to a "filled" variable to indicate whether a userspace
    buffer did get filled in (for fiemap, hole "extents" are skipped).

    I'm just using the getbmapx struct as a "common denominator" because
    as far as I can see, it holds all info that any formatters will care
    about.

    ("*thing" because fiemap doesn't pass the user pointer around, but rather
    has a pointer to a fiemap info structure, and helpers associated with it)

    Signed-off-by: Eric Sandeen
    Reviewed-by: Christoph Hellwig
    Signed-off-by: Niv Sardi

    Eric Sandeen
     

28 Jul, 2008

2 commits

  • xfs_attrmulti_by_handle currently request the size based on
    sizeof(attr_multiop_t) but should be using sizeof(xfs_attr_multiop_t)
    because that is what it is dealing with. Despite beeing wrong this
    actually harmless in practice because both structures are the same size on
    all platforms.

    But this sizeof was the only user of struct attr_multiop so we can just
    kill it. Also move the ATTR_OP_* defines xfs_attr.h into the struct
    xfs_attr_multiop defintion in xfs_fs.h because they are only used with
    that structure, and are part of the user ABI for the
    XFS_IOC_ATTRMULTI_BY_HANDLE ioctl.

    SGI-PV: 983508

    SGI-Modid: xfs-linux-melb:xfs-kern:31352a

    Signed-off-by: Christoph Hellwig
    Signed-off-by: Tim Shimmin
    Signed-off-by: Lachlan McIlroy

    Christoph Hellwig
     
  • Implement ASCII case-insensitive support. It's primary purpose is for
    supporting existing filesystems that already use this case-insensitive
    mode migrated from IRIX. But, if you only need ASCII-only case-insensitive
    support (ie. English only) and will never use another language, then this
    mode is perfectly adequate.

    ASCII-CI is implemented by generating hashes based on lower-case letters
    and doing lower-case compares. It implements a new xfs_nameops vector for
    doing the hashes and comparisons for all filename operations.

    To create a filesystem with this CI mode, use: # mkfs.xfs -n version=ci

    SGI-PV: 981516
    SGI-Modid: xfs-linux-melb:xfs-kern:31209a

    Signed-off-by: Barry Naujok
    Signed-off-by: Christoph Hellwig

    Barry Naujok
     

07 Feb, 2008

1 commit

  • XFS_IOC_GETVERSION, XFS_IOC_GETXFLAGS and XFS_IOC_SETXFLAGS all take a
    "long" which changes size between 32 and 64 bit platforms.

    So, the ioctl cmds that come in from a 32-bit app aren't as expected, for
    example on GETXFLAGS,

    unknown cmd fd(3) cmd(80046601){t:'f';sz:4}

    due to the size mismatch.

    So, use instead the 32-bit version of the commands for compat ioctls, and
    other than that it doesn't take any more manipulation.

    Also, for both native and compat versions, just define them to the values
    as defined in fs.h

    SGI-PV: 971186
    SGI-Modid: xfs-linux-melb:xfs-kern:29849a

    Signed-off-by: Eric Sandeen
    Signed-off-by: Lachlan McIlroy
    Signed-off-by: Tim Shimmin

    Eric Sandeen
     

19 Oct, 2007

1 commit

  • Currently XFs has three different fid types: struct fid, struct xfs_fid
    and struct xfs_fid2 with hte latter two beeing identicaly and the first
    one beeing the same size but an unstructured array with the same size.

    This patch consolidates all this to alway uuse struct xfs_fid.

    This patch is required for an upcoming patch series from me that revamps
    the nfs exporting code and introduces a Linux-wide struct fid.

    SGI-PV: 970336
    SGI-Modid: xfs-linux-melb:xfs-kern:29651a

    Signed-off-by: Christoph Hellwig
    Signed-off-by: Lachlan McIlroy
    Signed-off-by: Tim Shimmin

    Christoph Hellwig
     

14 Jul, 2007

2 commits

  • In media spaces, video is often stored in a frame-per-file format. When
    dealing with uncompressed realtime HD video streams in this format, it is
    crucial that files do not get fragmented and that multiple files a placed
    contiguously on disk.

    When multiple streams are being ingested and played out at the same time,
    it is critical that the filesystem does not cross the streams and
    interleave them together as this creates seek and readahead cache miss
    latency and prevents both ingest and playout from meeting frame rate
    targets.

    This patch set creates a "stream of files" concept into the allocator to
    place all the data from a single stream contiguously on disk so that RAID
    array readahead can be used effectively. Each additional stream gets
    placed in different allocation groups within the filesystem, thereby
    ensuring that we don't cross any streams. When an AG fills up, we select a
    new AG for the stream that is not in use.

    The core of the functionality is the stream tracking - each inode that we
    create in a directory needs to be associated with the directories' stream.
    Hence every time we create a file, we look up the directories' stream
    object and associate the new file with that object.

    Once we have a stream object for a file, we use the AG that the stream
    object point to for allocations. If we can't allocate in that AG (e.g. it
    is full) we move the entire stream to another AG. Other inodes in the same
    stream are moved to the new AG on their next allocation (i.e. lazy
    update).

    Stream objects are kept in a cache and hold a reference on the inode.
    Hence the inode cannot be reclaimed while there is an outstanding stream
    reference. This means that on unlink we need to remove the stream
    association and we also need to flush all the associations on certain
    events that want to reclaim all unreferenced inodes (e.g. filesystem
    freeze).

    SGI-PV: 964469
    SGI-Modid: xfs-linux-melb:xfs-kern:29096a

    Signed-off-by: David Chinner
    Signed-off-by: Barry Naujok
    Signed-off-by: Donald Douwsma
    Signed-off-by: Christoph Hellwig
    Signed-off-by: Tim Shimmin
    Signed-off-by: Vlad Apostolov

    David Chinner
     
  • When we have a couple of hundred transactions on the fly at once, they all
    typically modify the on disk superblock in some way.
    create/unclink/mkdir/rmdir modify inode counts, allocation/freeing modify
    free block counts.

    When these counts are modified in a transaction, they must eventually lock
    the superblock buffer and apply the mods. The buffer then remains locked
    until the transaction is committed into the incore log buffer. The result
    of this is that with enough transactions on the fly the incore superblock
    buffer becomes a bottleneck.

    The result of contention on the incore superblock buffer is that
    transaction rates fall - the more pressure that is put on the superblock
    buffer, the slower things go.

    The key to removing the contention is to not require the superblock fields
    in question to be locked. We do that by not marking the superblock dirty
    in the transaction. IOWs, we modify the incore superblock but do not
    modify the cached superblock buffer. In short, we do not log superblock
    modifications to critical fields in the superblock on every transaction.
    In fact we only do it just before we write the superblock to disk every
    sync period or just before unmount.

    This creates an interesting problem - if we don't log or write out the
    fields in every transaction, then how do the values get recovered after a
    crash? the answer is simple - we keep enough duplicate, logged information
    in other structures that we can reconstruct the correct count after log
    recovery has been performed.

    It is the AGF and AGI structures that contain the duplicate information;
    after recovery, we walk every AGI and AGF and sum their individual
    counters to get the correct value, and we do a transaction into the log to
    correct them. An optimisation of this is that if we have a clean unmount
    record, we know the value in the superblock is correct, so we can avoid
    the summation walk under normal conditions and so mount/recovery times do
    not change under normal operation.

    One wrinkle that was discovered during development was that the blocks
    used in the freespace btrees are never accounted for in the AGF counters.
    This was once a valid optimisation to make; when the filesystem is full,
    the free space btrees are empty and consume no space. Hence when it
    matters, the "accounting" is correct. But that means the when we do the
    AGF summations, we would not have a correct count and xfs_check would
    complain. Hence a new counter was added to track the number of blocks used
    by the free space btrees. This is an *on-disk format change*.

    As a result of this, lazy superblock counters are a mkfs option and at the
    moment on linux there is no way to convert an old filesystem. This is
    possible - xfs_db can be used to twiddle the right bits and then
    xfs_repair will do the format conversion for you. Similarly, you can
    convert backwards as well. At some point we'll add functionality to
    xfs_admin to do the bit twiddling easily....

    SGI-PV: 964999
    SGI-Modid: xfs-linux-melb:xfs-kern:28652a

    Signed-off-by: David Chinner
    Signed-off-by: Christoph Hellwig
    Signed-off-by: Tim Shimmin

    David Chinner
     

28 Sep, 2006

1 commit


09 Jun, 2006

2 commits


11 Jan, 2006

2 commits


02 Nov, 2005

2 commits


21 Jun, 2005

2 commits


17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds