linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Roberto Spadim <roberto@spadim.com.br>
To: hank peng <pengxihan@gmail.com>
Cc: linux-raid <linux-raid@vger.kernel.org>
Subject: Re: why disk errors are more likely to happen on md super block area?
Date: Fri, 25 Mar 2011 00:42:59 -0300	[thread overview]
Message-ID: <AANLkTimA0WccEAKOyxR7WAMqhvAJfgpsC-5dU-O=Cev5@mail.gmail.com> (raw)
In-Reply-To: <AANLkTikvUY1n5UYqTnK-djJvy0a_nmcTg0B8MPEfEw5T@mail.gmail.com>

humm head seek time? only testing to know if it will be decreased or not
the idea is: if md update metadata veryoften you should consider put
most i/o files near metadata sectors to don't lose time with head
positioning

real difference of metadata position?
maybe some bootloaders can't boot with md metadata at start/end of
disk/partition.
if you don't use this md device to boot, you don't need to worry about
it, any position will work, i don't know about growing array size
problems about meta data positioning, but i think you don't need to
worry about this too

2011/3/24 hank peng <pengxihan@gmail.com>:
> 2011/3/24 Roberto Spadim <roberto@spadim.com.br>:
>> i think you will have no problems with location of metadata, there's
>> some versions of metadata, at start at end.. check your mdadm --create
>> command
>
> yes, I found that option. If I choose to put metadata on the start
> area of a disk, disk's head seek time will be decreased, right?
>
> So, is there someone in this list to tell me what is real difference
> when putting meta data on start or end of a disk?
>
>> what information at metadata is/was wrong? can you get it? or just i/o error?
>> some months ago i had two broken harddisks, the disk start to read
>> from position 0 to position X without problem, but when it get at a
>> position where disk was crashed (real crashed, the disk hit the floor)
>> the array start to resync (maybe a disk report) it was a raid10 array.
>> maybe you have problem at physical layer (disk with problem).
>> i don't know what informations md update at metadata, but i think that
>> there's some last write counter/last write timestamp to sync what
>> mirrors is more recent in a broken array start, (this information can
>> be found with others developers in this list)
>>
>> 2011/3/23 hank peng <pengxihan@gmail.com>:
>>> Hi, guys:
>>> I found that when disk errors happened, it is more likely to locate in
>>> md super block area. Kernel messages are like this:
>>> end_request: I/O error, dev sda, sector 1953525000
>>> md: super_written gets error=-5, uptodate=0
>>> In some cases, I check if disk is really failed using 'dd' command and
>>> found that it is OK for read and write on those sectors.
>>>
>>> I know that md super block information is located in the end of a
>>> disk, but is it related with this problem? Is it safer to put md super
>>> block in the start area of a disk?
>>>
>>>
>>> --
>>> The simplest is not all best but the best is surely the simplest!
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>
>>
>>
>> --
>> Roberto Spadim
>> Spadim Technology / SPAEmpresarial
>>
>
>
>
> --
> The simplest is not all best but the best is surely the simplest!
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Roberto Spadim
Spadim Technology / SPAEmpresarial
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

      reply	other threads:[~2011-03-25  3:42 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-24  1:34 why disk errors are more likely to happen on md super block area? hank peng
2011-03-24  3:48 ` Roberto Spadim
2011-03-25  2:27   ` hank peng
2011-03-25  3:42     ` Roberto Spadim [this message]

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='AANLkTimA0WccEAKOyxR7WAMqhvAJfgpsC-5dU-O=Cev5@mail.gmail.com' \
    --to=roberto@spadim.com.br \
    --cc=linux-raid@vger.kernel.org \
    --cc=pengxihan@gmail.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).