[lkml]   [2008]   [Jul]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subject[RFC] Disk shock protection in GNU/Linux
    Hi all,

    yet again, I'm trying to get this feature into the Linux kernel. This
    time, I have tried to arrange the code in such a way that hardly
    anything not strictly belonging to the libata or ide subsystem is
    touched at all. Since former attempts to design this in a more generic
    way involving the block and scsi layer have proven very difficult and
    since this is all about an ATA specific feature anyway, I think the best
    solution (for now at least) is to stick to those two subsystems as far
    as possible.

    Nevertheless, I'd welcome James' opinion on the third patch in the
    series with regard to the use of vendor specific cdbs. If it is
    acceptable in principle, the question remains whether we sould reserve
    part of the range 0xf800 - 0xffff of vendor specific service actions for
    the exclusive use by LLDDs (in much the way I did it here), or whether
    all these codes should be unique in the kernel and defined in scsi.h.

    Also, we have to agree upon a suitable way to deal with devices that
    actually do support the UNLOAD FEATURE but don't report that capability
    in their ID as specified in ATA-7. Perhaps we even want to fall back to
    STANDBY IMMEDIATE on devices that definitely don't support IDLE
    IMMEDIATE with UNLOAD FEATURE; this has been the case for the original
    hdaps / disk-protect patch but I'm not quite sure whether anybody
    actually relies on this feature and whether it would be advisable in the
    first place. Regarding devices that support head unloading but don't
    report it properly, there seem to be the following options:

    a) Provide an attribute in sysfs for the user to indicate that the
    device really does support the UNLOAD FEATURE.
    b) Issue the command (for the first time) anyway and check whether the
    device responds as specified in ATA-7. Make a note of the result and
    act accordingly from there on.

    The second option looks appealing because no user intervention is
    required and it is known to work at least for some devices. On the other
    hand, it may be dangerous on old hardware and I don't even know whether
    all pre-ATA-7 devices supporting the UNLOAD FEATURE really do return the
    correct data in the command registers.

    Here is a short description of the patches in this series applying
    cleanly on top of next-20080725:

    1. This is a trivial patch making things slightly easier for #3. More
    importantly though, it also fixes a potential memory leak and should
    probably be applied regardless of the rest of the series (Jeff?).
    2. This is a small patch to ata.h in order to provide a simple check for
    support of the UNLOAD FEATURE as indicated in a device's ID.
    3. Here disk head unloading is implemented in the libata subsystem. See
    the changelog entry for current shortcomings of this patch.
    4. The same for ide.
    5. A little bit of documentation.

    There are some questions I need your advice on that have been inserted
    as FIXME comments into the code. However, here is a more general
    question that interests me even though it could turn out to be a good
    idea (or at least acceptable) to merge these patches before that
    question has been fully resolved. Alan once mentioned that it might be
    desirable to abort commands currently in progress and issue IDLE
    IMMEDIATE straight away. My question is whether this is at all possible
    for non SATA command protocols. In volume 2 of the ATA-7 specification I
    haven't found a well defined way to abort or shor circuit, say, a DMA or
    PIO command in progress. It even says that after the host has aborted
    data transfer when DMA was in progress, it is supposed to initiate a
    SRST. Obviously, I'd like to avoid that at all costs.

    Thank you in advance for your cooperation,


     \ /
      Last update: 2008-07-26 08:23    [W:0.025 / U:89.748 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site