[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: dd for failing discs?
From: |
Pádraig Brady |
Subject: |
Re: dd for failing discs? |
Date: |
Wed, 26 Feb 2014 01:15:41 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 |
On 02/25/2014 05:56 PM, Bernhard Voelker wrote:
> re-adding the ML.
>
> On 02/18/2014 07:43 AM, Bernhard Voelker wrote:
>> On 02/17/2014 01:46 PM, Pádraig Brady wrote:
>>> On 02/14/2014 01:55 AM, Bernhard Voelker wrote:
>>>> Can short reads not also happen with block devices?
>>>
>>> Theoretically possible possible I suppose.
>>> Though for regular files backed by block devices the task will go
>>> into non-interruptible sleep from the read call, and thus not return early.
>>> This is kind of a UNIX law which would be very awkward to change.
>>>
>>> Though POSIX does say:
>>>
>>> "The issue of which files or file types are interruptible is considered an
>>> implementation design issue. This is often affected primarily by hardware
>>> and reliability issues."
>>>
>>> So it is safer to use fullblock, and in your description I'd
>>> mention that 'fullblock' is used to cater for short reads
>>> (which traditionally never occur on disk based devices),
>>> and 'sync' is used to pad out bad reads with NULs.
>>>
>>> Avoid nondescript phrases like "might be helpful".
>>> Simply state in which cases the option is useful.
>>> 'noerror' would be required for this use case for example.
>>
>> Thanks for clarifying.
>>
>> [...], so an amended
>> version of the patch will take a few days.
>
>
>>From e9e089cf4053e7f016e58deb12dbb530bddf18bb Mon Sep 17 00:00:00 2001
> From: Bernhard Voelker <address@hidden>
> Date: Tue, 25 Feb 2014 18:50:27 +0100
> Subject: [PATCH] doc: add dd example for failing disks
>
> * doc/coreutils.texi (dd invocation): Add an example for how to call
> dd to save data from a failing disk. Mention GNU 'ddrescue' as one
> of the more specialized tools in such a case.
> ---
> doc/coreutils.texi | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/doc/coreutils.texi b/doc/coreutils.texi
> index 95453c7..5e3b402 100644
> --- a/doc/coreutils.texi
> +++ b/doc/coreutils.texi
> @@ -8928,6 +8928,24 @@ tape=/dev/rmt/0
> (dd bs=4k seek=1 count=0 && dd bs=512k) <$tape >$disk
> @end example
>
> +@cindex ddrescue
> +@cindex disks, failing
> +For failing disks, other tools come with a great variety of extra
> +functionality to ease the saving of as much data as possible before the
> +disk finally dies, e.g.
> +@uref{http://www.gnu.org/software/ddrescue/, GNU @command{ddrescue}}.
> +However, in some cases such a tool is not available or the administrator
> +feels more comfortable with the handling of @command{dd}.
> +As a simple rescue method, call @command{dd} as shown in the following
> +example: the options @samp{conv=noerror,sync} are used to continue
> +after read errors and to pad out bad reads with NULs, while
> +@samp{iflag=fullblock} safely caters for short reads:
s/safely caters for short reads/
caters for short reads (which traditionally never occur on disk based
devices)/
For my own reference on this point POSIX says:
"The issue of which files or file types are interruptible is considered an
implementation design issue. This is often affected primarily by hardware
and reliability issues."
Otherwise +1
thanks,
Pádraig.