From: Hullen@t-online.de (Helmut Hullen)
To: linux-btrfs@vger.kernel.org
Subject: Re: failed disk
Date: 09 May 2012 17:14:00 +0200 [thread overview]
Message-ID: <C8XJ9Fm9CXB@helmut.hullen.de> (raw)
In-Reply-To: <20120509143735.GQ8938@carfax.org.uk>
Hallo, Hugo,
Du meintest am 09.05.12:
>>> mkfs.btrfs -m raid1 -d single should give you that.
>> Just a small bug, perhaps:
>>
>> created a system with
>>
>> mkfs.btrfs -m raid1 -d single /dev/sdl1
>> mount /dev/sdl1 /mnt/Scsi
>> btrfs device add /dev/sdk1 /mnt/Scsi
>> btrfs device add /dev/sdm1 /mnt/Scsi
>> (filling with data)
>>
>> and
>>
>> btrfs fi df /mnt/Scsi
>>
>> now tells
>>
>> Data, RAID0: total=183.18GB, used=76.60GB
>> Data: total=80.01GB, used=79.83GB
>> System, DUP: total=8.00MB, used=32.00KB
>> System: total=4.00MB, used=0.00
>> Metadata, DUP: total=1.00GB, used=192.74MB
>> Metadata: total=8.00MB, used=0.00
>>
>> --------------------------------------
>>
>> "Data, RAID0" confuses me (not very much ...), and the system for
>> metadata (RAID1) is not told.
> DUP is two copies of each block, but it allows the two copies to
> live on the same device. It's done this because you started with a
> single device, and you can't do RAID-1 on one device. The first bit
> of metadata you write to it should automatically upgrade the DUP
> chunk to RAID-1.
Ok.
Sounds familiar - have you explained that to me many months ago?
> As to the spurious "upgrade" of single to RAID-0, I thought Ilya
> had stopped it doing that. What kernel version are you running?
3.2.9, self made.
I could test the message with 3.3.4, but not today (if it's only an
interpretation of always the same data).
> Out of interest, why did you do the device adds separately,
> instead of just this?
a) making the first 2 devices: I have tested both versions (one line
with 2 devices or 2 lines with 1 device); no big difference.
But I had tested the option "-L" (labelling) too, and that makes shit
for the oneliner: both devices get the same label, and then "findfs"
finds none of them.
The really safe way would be: deleting this option for the "mkfs.btrfs"
command and only using
btrfs fi label <device> [<newlabel>]
b) third device: that's my usual test:
make a cluster of 2 deivces
fill them with data
add a third device
delete the smallest device
Viele Gruesse!
Helmut
next prev parent reply other threads:[~2012-05-09 15:14 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-07 10:46 kernel 3.3.4 damages filesystem (?) Helmut Hullen
2012-05-07 10:58 ` Fajar A. Nugraha
2012-05-07 12:06 ` Helmut Hullen
2012-05-07 10:59 ` Hugo Mills
2012-05-07 12:15 ` Helmut Hullen
2012-05-07 13:34 ` Helmut Hullen
2012-05-07 14:05 ` Hugo Mills
2012-05-07 16:36 ` Helmut Hullen
2012-05-07 17:13 ` Felix Blanke
2012-05-07 17:52 ` Helmut Hullen
2012-05-07 18:00 ` Hugo Mills
2012-05-07 18:25 ` Helmut Hullen
2012-05-07 18:44 ` Hugo Mills
2012-05-09 13:04 ` failed disk (was: kernel 3.3.4 damages filesystem (?)) Helmut Hullen
2012-05-09 13:19 ` Hugo Mills
2012-05-09 14:25 ` Helmut Hullen
2012-05-09 14:37 ` Hugo Mills
2012-05-09 15:14 ` Helmut Hullen [this message]
2012-05-09 15:33 ` failed disk Hugo Mills
2012-05-09 18:49 ` Helmut Hullen
2012-05-09 16:13 ` failed disk (was: kernel 3.3.4 damages filesystem (?)) Ilya Dryomov
2012-05-10 2:49 ` failed disk Helmut Hullen
2012-05-07 19:30 ` kernel 3.3.4 damages filesystem (?) Daniel Lee
2012-05-07 20:21 ` Helmut Hullen
2012-05-07 20:51 ` Daniel Lee
2012-05-07 21:17 ` Helmut Hullen
2012-05-07 21:27 ` cwillu
2012-05-07 22:07 ` Martin Steigerwald
2012-05-08 7:39 ` Helmut Hullen
2012-05-08 7:44 ` Fajar A. Nugraha
2012-05-08 10:00 ` Helmut Hullen
2012-05-08 10:41 ` Clemens Eisserer
2012-05-08 13:13 ` Helmut Hullen
2012-05-08 13:44 ` Felix Blanke
2012-05-08 13:52 ` Hugo Mills
2012-05-08 16:53 ` Helmut Hullen
2012-05-08 17:24 ` Felix Blanke
2012-05-08 18:29 ` Helmut Hullen
2012-05-08 18:41 ` Felix Blanke
2012-05-08 19:12 ` David Sterba
2012-05-08 19:34 ` Helmut Hullen
2012-05-08 20:02 ` Hugo Mills
2012-05-08 20:19 ` Helmut Hullen
2012-05-08 20:56 ` Roman Mamedov
2012-05-09 14:46 ` Kaspar Schleiser
2012-05-10 10:40 ` Martin Steigerwald
2012-05-10 11:55 ` feature request (was: kernel 3.3.4 damages filesystem (?)) Helmut Hullen
2012-05-10 19:43 ` kernel 3.3.4 damages filesystem (?) Hubert Kario
2012-05-10 20:15 ` Hugo Mills
2012-05-10 20:23 ` Hubert Kario
2012-05-08 21:42 ` Hubert Kario
2012-05-07 12:53 ` Liu Bo
2012-05-09 17:32 ` Duncan
2012-05-09 18:06 ` Atila
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=C8XJ9Fm9CXB@helmut.hullen.de \
--to=hullen@t-online.de \
--cc=helmut@hullen.de \
--cc=linux-btrfs@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.