[lkml]   [1999]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: RFC: from FIBMAP to FIONDEV
    Matthew Wilcox wrote:
    > On Fri, Jun 11, 1999 at 12:42:15PM +0200, Werner Almesberger wrote:
    >> I'm not so sure what to do about RAIDs.

    Well, the longer I think about it, the less I'm convinced anything special
    should be done for RAIDs, except for issuing a warning and trying to get
    things to work in a non-redundant way.

    IMHO, a useful "generic" approach is to replicate the boot loader simply
    by installing it on a non-RAID partition on each disk of the RAID, and
    perhaps to have a means to fail over to another disk if the boot disk is
    the one with problems. In the case of LILO, the failover can either be at
    the level of picking a different boot image, or it could also be a special
    MBR that is run before LILO and that checks for some keypress or such.

    Once we have a compact and reliable scheme for detecting the valid copy in
    a partially defunct RAID, this can be added to that special MBR.

    One thing that may be useful then is to be able to boot a kernel directly
    from Linux. That way, kernels can be stored on the RAID and the boot
    partitions have a known small size.

    Does this sound good to all the RAIDers out there ?

    Another thing I've realized is that, for consistency, FIONDEV should also
    map partitions to whole disks. I've attached the updated description.

    I'm in no particular rush on this one, but given that it takes quite a
    while to propagate such an extension, I'd like to get as much right as
    possible, so please comment if you see anything wrong.

    - Werner

    ---------------------------------- cut here -----------------------------------

    About two years ago, when there was much discussion about reiserfs, md,
    and other advanced file system structures, it became apparent that good
    old FIBMAP wasn't sufficient. So I proposed a successor for it called
    FIPHYLOC. Fortunately, this one never made it into the mainstream
    kernel ;-)

    Now I have a much improved design. It adds the following new features
    (with respect to FIBMAP):

    - works with byte granularity, so it can handle files with data starting
    at a non-zero offset in blocks (e.g. "block splitting" in reiserfs and
    SGI's XFS)
    - also returns the device number, so it can handle files spread over
    multiple block devices (e.g. md, LVM)
    - translates partitions to the whole disk device, so the caller doesn't
    have to know the numbering structure
    - returns areas of consecutive bytes, not individual block addresses, so
    fewer ioctls are required
    - can report various anomalies, such as unstable or ambiguous storage
    (see below; with FIBMAP, the caller had to know every single special

    I've attached a detailed description. I'll work on a kernel patch and the
    corresponding extension of LILO once this has stabilized.

    Opinions welcome.

    - Werner

    ----- Items to be added to linux/fs.h -----------------------------------------

    #define FIONDEV _IOW(0x00,3,struct fiondev_result)
    /* get the location of the contiguous area on the underlying block
    device, which contains data of the file or block device, starting at
    the current file position. */

    * Flags returned by FIONDEV

    #define FIONDEV_ERROR 1 /* request failed, no data was returned */
    #define FIONDEV_VOLATILE 2 /* location is temporary (e.g. scratch file,
    RAM disk) */
    #define FIONDEV_COPIES 4 /* location is replicated */
    #define FIONDEV_MISALIGNED 8 /* current file position it not at a boundary */
    #define FIONDEV_FINAL 16 /* "device" is a physical device requiring no
    further translation */

    struct fiondev_result {
    int flags; /* FIONDEV_* flags */
    dev_t device; /* underlying block device */
    loff_t start; /* byte offset in block device */
    loff_t size; /* area size (in bytes); 0 at EOF; may exceed
    file or block device size */


    FIONDEV can be applied to files and to block devices. It returns the
    location of data at the current file position on the underlying block
    device. The information returned describes a consecutive area on the
    block device, determined by its start and its size. FIONDEV advances
    the file pointer to the end of this data area.

    FIONDEV can be applied recursively to obtain the actual physical
    location of a file, e.g. file -> loop device -> (file) -> md (RAID) ->
    disk partition -> SCSI disk. "(file)" is implicitly done by the loop

    Note that the size returned may actually exceed the size of the file
    or the block device being queried. It is the responsibility of the
    caller to use only information that corresponds to actually available
    data areas. Likewise, the size returned be may less than the actual
    contiguous area. (E.g. in the case of consecutive extents.)

    If the current file position is at the end of the file or device,
    "size" is set to zero. The value of the fields "device" and "start"
    is undefined in this case.

    Unmapped areas ("holes") should be returned with "device" and "start"
    set to zero.

    "Whole disk" block devices with no underlying devices should set
    FIONDEV_FINAL, return their own device number in the device field,
    the current file position in "start", and a value corresponding at
    least to the size of the device in "size".

    Block devices corresponding to a partition should return the
    respective "whole disk" device. This way, the user does not have to
    know the device number structure used for partitions.

    FIONDEV may return the following flags:

    The content of the other fields in the result structure is
    undefined. Additional flags may be set to indicate the failure
    reason. The current file position may be undefined. No further
    FIONDEV ioctls should be issued before closing the file.

    Location is on unstable storage, e.g. in a designated temporary
    file, a RAM disk, etc. Boot loaders must not map such areas.
    Files or block devices that are completely unsuitable for mapping
    should set FIONDEV_ERROR in addition to FIONDEV_VOLATILE.

    Data is contained in multiple areas, e.g. replicated on several
    volumes in a RAID array. A boot loader may use this information,
    but by doing so, it may not preserve all of the semantics of the
    storage. (E.g. in the case of a RAID, the RAID storage itself may
    survive the failure of some disks, but a boot loader may fail if
    the disks it mapped are among the ones that failed.)

    If there are multiple locations at which the physically same data
    block can be found, FIONDEV_COPIES should only be set if none of
    them can be relied to remain valid. Otherwise, the most long-lived
    location should be returned.

    The current position is not at the beginning of a contiguous data
    area on the underlying block device. Setting this flag is optional.
    However, if no data is returned as a result of this condition (i.e.
    if FIONDEV_ERROR is set), FIONDEV_MISALIGNED must be set to
    indicate the reason.

    No further resolution is necessary on the device returned. This
    flag must be set by all physical "whole disk" devices when FIONDEV
    is invoked on them. It may also be set on the last translation step
    leading to a physical "whole disk" device, thereby eliminating a
    redundant FIONDEV ioctl.

    If the physical location of a file or device changes during mapping,
    subsequent FIONDEV ioctls may fail. Note however that extensively
    probing for such a condition would be a wasted effort, because changes
    could always occur right after mapping.

    During migration from FIBMAP to FIONDEV (i.e. for the next few years),
    any errno-style errors returned by FIONDEV should be interpreted as lack
    of support for FIONDEV. In order to ease migration, FIONDEV should only
    return a negative value (i.e. report an errno-style error) for
    conditions that cannot be described in more detail using flags.

    / Werner Almesberger, ICA, EPFL, CH /

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:52    [W:0.058 / U:13.556 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site