LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Elias Oltmanns <eo@nebensachen.de>
To: Pavel Machek <pavel@ucw.cz>
Cc: Jens Axboe <jens.axboe@oracle.com>,
	Christoph Schmid <chris@schlagmichtod.de>,
	linux-kernel@vger.kernel.org
Subject: Re: is there any Hard-disk shock-protection for 2.6.18 and above?
Date: Thu, 08 Feb 2007 11:04:10 +0100	[thread overview]
Message-ID: <87ps8lj78l.fsf@denkblock.local> (raw)
In-Reply-To: <20070204204115.GC2067@elf.ucw.cz> (Pavel Machek's message of "Sun\, 4 Feb 2007 21\:41\:15 +0100")

Hi Pavel,

Pavel Machek <pavel@ucw.cz> wrote:
> Hi1
>
>> >> >> +module_param_named(protect_method, libata_protect_method, int, 0444);
>> >> >> +MODULE_PARM_DESC(protect_method, "hdaps disk protection method  (0=autodetect, 1=unload, 2=standby)");
>> >> >
>> >> > Should this be configurable by module parameter? Why not tell each
>> >> > unload what to do?
>> [...]
>> >> > Is /sys interface right thing to do?
>> >> 
>> >> Probably, you're right here. Since this feature is actually drive
>> >> specific, it should not really be set globally as a libata or ide-disk
>> >> parameter but specifically for each drive connected. Perhaps we should
>> >> add another attribute to /sys/block/*/queue or enhance the scope of
>> >> /sys/block/*/queue/protect?
>> >
>> > Certainly better than current solution. Or maybe ioctl similar to wat
>> > hdparm uses?
>> 
>> I'm not quite sure what you have in mind wrt ioctls. I'm still
>> convinced that the administrator should take a conscious decision when
>> forcing an idle immediate with unload feature on a drive which doesn't
>> announce this capability according to the specs. This is because I
>> have no idea as to how drives might react if they don't support it.
>> Perhaps we should consult linux-ide on this topic.
>
> Yep, I guess linux-ide would have some comments.

At least, I can now see the benefits of an ioctl approach. Although
the protect_method attribute allows to configure each drive
individually, that is actually not quite what we want. Since this
attribute is meant to deal with drives that don't comply strictly with
the ATA specs, it is, at least, misleading to associate this with each
queue. Instead, it would be desirable to offer this option to ATA
drives only and to do this consistently, regardless whether the IDE or
the ATA drivers are in use. So, I'm now quite convinced that ioctls
are the easiest way to achieve just that - thanks for the hint.

>
>> So, here is a patch in which your remarks and suggestions have been
>> incorporated. Additionally, I've added the requested kernel doc file
>
> Additional suggestion is to keep lines < 80 columns.... Sorry it took
> me so long to comment.
> 								Pavel

In the meantime, I've started to implement the generic block layer
commands for queue freezing as Jens suggested in this thread.
Unfortunately, I've been very busy lately and actually I still am but
I'll try hard to get this finished rather sooner thn later.

Thanks for your support.

Elias

  reply	other threads:[~2007-02-08 10:26 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <7ibks-1fg-15@gated-at.bofh.it>
     [not found] ` <7kpjn-7th-23@gated-at.bofh.it>
     [not found]   ` <7kDFF-8rd-29@gated-at.bofh.it>
2006-11-27 18:31     ` Elias Oltmanns
2006-11-30 17:19       ` Pavel Machek
2006-11-30 17:51         ` Shem Multinymous
2006-12-01 14:19         ` Elias Oltmanns
2006-12-02 11:57           ` Pavel Machek
2006-12-10  1:02             ` Elias Oltmanns
2006-12-10  1:16               ` Elias Oltmanns
2006-12-11  8:26                 ` Jens Axboe
2007-02-04 20:41               ` Pavel Machek
2007-02-08 10:04                 ` Elias Oltmanns [this message]
2006-11-30 18:43       ` Jens Axboe
2006-11-17 12:47 Christoph Schmid
2006-11-21 20:51 ` Pavel Machek
2006-11-23 18:26   ` Shem Multinymous
2006-11-30 17:11     ` Pavel Machek
2006-11-30 17:47       ` Shem Multinymous
2006-11-24  7:21   ` Jens Axboe
2006-11-26 23:14     ` Jon Escombe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ps8lj78l.fsf@denkblock.local \
    --to=eo@nebensachen.de \
    --cc=chris@schlagmichtod.de \
    --cc=jens.axboe@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --subject='Re: is there any Hard-disk shock-protection for 2.6.18 and above?' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).