Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #190325 > unrolled thread

Experiences with BTRFS -- is it mature enough for enterprise use?

Back to article view | Back to linux.debian.user

Contents

  Experiences with BTRFS -- is it mature enough for enterprise use? Rick Thomas <rbthomas@pobox.com> - 2017-12-26 20:50 +0100
    Re: Experiences with BTRFS -- is it mature enough for enterprise use? Eero Volotinen <eero.volotinen@iki.fi> - 2017-12-26 20:50 +0100
      Re: Experiences with BTRFS -- is it mature enough for enterprise use? Roberto C. Sánchez <roberto@debian.org> - 2017-12-26 23:30 +0100
        Re: Experiences with BTRFS -- is it mature enough for enterprise use? Sven Hartge <sven@svenhartge.de> - 2017-12-27 00:00 +0100
        Re: Experiences with BTRFS -- is it mature enough for enterprise use? Michael Stone <mstone@debian.org> - 2017-12-27 00:40 +0100
    Re: Experiences with BTRFS -- is it mature enough for enterprise use? Jan Vales <jan@jvales.net> - 2017-12-26 21:30 +0100
    Re: Experiences with BTRFS -- is it mature enough for enterprise use? Andy Smith <andy@strugglers.net> - 2017-12-26 22:40 +0100
    Re: Experiences with BTRFS -- is it mature enough for enterprise use? David Christensen <dpchrist@holgerdanske.com> - 2017-12-27 04:10 +0100
      Re: Experiences with BTRFS -- is it mature enough for enterprise use? Matthew Crews <mailinglists@mattcrews.com> - 2017-12-27 13:00 +0100
        Re: Experiences with BTRFS -- is it mature enough for enterprise use? Tom Dial <tddial@comcast.net> - 2017-12-27 23:10 +0100
          Re: Experiences with BTRFS -- is it mature enough for enterprise use? Rick Thomas <rick.thomas@pobox.com> - 2017-12-28 02:10 +0100
            Re: Experiences with BTRFS -- is it mature enough for enterprise use? deloptes <deloptes@gmail.com> - 2017-12-28 02:20 +0100
              Re: Experiences with BTRFS -- is it mature enough for enterprise use? Eero Volotinen <eero.volotinen@iki.fi> - 2017-12-28 07:10 +0100
                Re: Experiences with BTRFS -- is it mature enough for enterprise use? Dan Ritter <dsr@randomstring.org> - 2017-12-28 17:00 +0100
                  Re: Experiences with BTRFS -- is it mature enough for enterprise use? Eero Volotinen <eero.volotinen@iki.fi> - 2017-12-28 18:30 +0100
                    Re: Experiences with BTRFS -- is it mature enough for enterprise use? Glenn English <ghe2001@gmail.com> - 2017-12-28 20:40 +0100
                      Re: Experiences with BTRFS -- is it mature enough for enterprise use? Matthew Crews <mailinglists@mattcrews.com> - 2017-12-28 20:50 +0100
                      Re: Experiences with BTRFS -- is it mature enough for enterprise use? Andy Smith <andy@strugglers.net> - 2017-12-29 01:00 +0100
                        Re: Experiences with BTRFS -- is it mature enough for enterprise use? Jan Vales <jan@jvales.net> - 2017-12-30 00:50 +0100
                          Re: Experiences with BTRFS -- is it mature enough for enterprise use? Matthew Crews <mailinglists@mattcrews.com> - 2017-12-30 01:30 +0100
                            Re: Experiences with BTRFS -- is it mature enough for enterprise use? Jan Vales <jan@jvales.net> - 2017-12-30 01:40 +0100
                              Re: Experiences with BTRFS -- is it mature enough for enterprise use? Matthew Crews <mailinglists@mattcrews.com> - 2017-12-30 23:40 +0100
                                Re: Experiences with BTRFS -- is it mature enough for enterprise use? David Christensen <dpchrist@holgerdanske.com> - 2017-12-31 07:20 +0100
                                  Re: Experiences with BTRFS -- is it mature enough for enterprise use? Sven Hartge <sven@svenhartge.de> - 2017-12-31 18:50 +0100
                                    Re: Experiences with BTRFS -- is it mature enough for enterprise use? David Christensen <dpchrist@holgerdanske.com> - 2017-12-31 23:10 +0100
                                      Re: Experiences with BTRFS -- is it mature enough for enterprise use? Sven Hartge <sven@svenhartge.de> - 2017-12-31 23:50 +0100
                                        Re: Experiences with BTRFS -- is it mature enough for enterprise use? David Christensen <dpchrist@holgerdanske.com> - 2018-01-02 03:10 +0100
                                          Re: Experiences with BTRFS -- is it mature enough for enterprise use? <tomas@tuxteam.de> - 2018-01-02 11:30 +0100
                                            Re: Experiences with BTRFS -- is it mature enough for enterprise use? David Christensen <dpchrist@holgerdanske.com> - 2018-01-02 17:40 +0100
                                              Re: Experiences with BTRFS -- is it mature enough for enterprise use? deloptes <deloptes@gmail.com> - 2018-01-02 19:10 +0100
                                                Re: Experiences with BTRFS -- is it mature enough for enterprise use? Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-01-02 20:10 +0100
                                                  Re: Experiences with BTRFS -- is it mature enough for enterprise use? deloptes <deloptes@gmail.com> - 2018-01-03 01:00 +0100
                                                    Re: Experiences with BTRFS -- is it mature enough for enterprise use? Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-01-04 00:00 +0100
                                                      Re: Experiences with BTRFS -- is it mature enough for enterprise use? deloptes <deloptes@gmail.com> - 2018-01-04 09:00 +0100
                                                        Re: Experiences with BTRFS -- is it mature enough for enterprise use? Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-01-04 20:20 +0100
                                                          Re: Experiences with BTRFS -- is it mature enough for enterprise use? deloptes <deloptes@gmail.com> - 2018-01-04 22:00 +0100
                                                      Re: Experiences with BTRFS -- is it mature enough for enterprise use? deloptes <deloptes@gmail.com> - 2018-01-04 12:00 +0100
                                                Re: Experiences with BTRFS -- is it mature enough for enterprise use? David Christensen <dpchrist@holgerdanske.com> - 2018-01-03 00:10 +0100
                                                  Re: Experiences with BTRFS -- is it mature enough for enterprise use? Darac Marjal <mailinglist@darac.org.uk> - 2018-01-03 00:50 +0100
                                                    Re: Experiences with BTRFS -- is it mature enough for enterprise use? Gene Heskett <gheskett@shentel.net> - 2018-01-03 02:10 +0100
                                                      Re: Experiences with BTRFS -- is it mature enough for enterprise use? Richard Hector <richard@walnut.gen.nz> - 2018-01-06 13:30 +0100
                                                    Re: Experiences with BTRFS -- is it mature enough for enterprise use? David Christensen <dpchrist@holgerdanske.com> - 2018-01-03 08:40 +0100
                                    Re: Experiences with BTRFS -- is it mature enough for enterprise use? Joel Wirāmu Pauling <joel@aenertia.net> - 2017-12-31 23:20 +0100
                                      Re: Experiences with BTRFS -- is it mature enough for enterprise use? Andy Smith <andy@strugglers.net> - 2018-01-03 04:40 +0100
                          Re: Experiences with BTRFS -- is it mature enough for enterprise use? Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-12-30 10:30 +0100
                    Re: Experiences with BTRFS -- is it mature enough for enterprise use? Dan Ritter <dsr@randomstring.org> - 2017-12-28 21:10 +0100
                Re: Experiences with BTRFS -- is it mature enough for enterprise use? deloptes <deloptes@gmail.com> - 2017-12-28 18:00 +0100
    Re: Experiences with BTRFS -- is it mature enough for enterprise use? Igor Cicimov <icicimov@gmail.com> - 2017-12-29 05:00 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#190462

[Multipart message — attachments visible in raw view] — view raw

On 12/30/17 01:26, Matthew Crews wrote:
>> -------- Original Message --------
>> Subject: Re: Experiences with BTRFS -- is it mature enough for enterprise use?
>> Local Time: December 29, 2017 4:48 PM
>> UTC Time: December 29, 2017 11:48 PM
>> From: jan@jvales.net
> 
>> You still can go md-raid + btrfs, if you want some btrfs features.
> 
> If you're using Raid1 or Raid10, md-raid + btrfs is probably worse than native btrfs Raid1 + Raid10.
> 

The problem with btrfs-raid10 (with 6 disks): it self-destructed itself
on our soon to be production server twice in december.

So no way btrfs-raid is going to see production on our machines anytime
soon.
It seems to work without issues on md-raid6 + luks + btrfs so far...
So hopefully we will at least have snaphots <3

Its just a file/backup-server and nothing that would need best disk
performance - if we wanted that, we would have gone for ssd's. :)

br,
Jan Vales
--
I only read plaintext emails.

[toc] | [prev] | [next] | [standalone]

#190471

>-------- Original Message --------
>Subject: Re: Experiences with BTRFS -- is it mature enough for enterprise use?
>Local Time: December 29, 2017 5:37 PM
>UTC Time: December 30, 2017 12:37 AM
>From: jan@jvales.net
> The problem with btrfs-raid10 (with 6 disks): it self-destructed itself
> on our soon to be production server twice in december.

That's a very unusual setup for raid10. I'm trying to understand how such a setup actually works. I know BTRFS Raid1 works with 3 disks, where it acts like a pseudo-raid5 (but not a true raid5). So with 6 disks in a raid10 setup, would it act like a pseudo-raid50?

Side note, with 6 disks, it might be better to use a Raid6 array instead of Raid10 or Raid5/50.

The main issue I see with using BTRFS with MDADM is that you lose the benefit of bit-rot repair. MDADM can't correct bit rot, but BTRFS-Raid (and ZFS raid arrays) can, but only with native raid configurations.

[toc] | [prev] | [next] | [standalone]

#190473

On 12/30/17 14:38, Matthew Crews wrote:
> The main issue I see with using BTRFS with MDADM is that you lose the benefit of bit-rot repair. MDADM can't correct bit rot, but BTRFS-Raid (and ZFS raid arrays) can, but only with native raid configurations.

AFAIK:

1.  mdadm RAID1 can fix bit rot, so long as one drive has a good block 
to fix the others.

2.  btrfs on top of mdadm RAID1 will not see the bit rot that mdadm 
RAID1 fixes.


David

[toc] | [prev] | [next] | [standalone]

#190490

David Christensen <dpchrist@holgerdanske.com> wrote:
> On 12/30/17 14:38, Matthew Crews wrote:

>> The main issue I see with using BTRFS with MDADM is that you lose the
>> benefit of bit-rot repair. MDADM can't correct bit rot, but
>> BTRFS-Raid (and ZFS raid arrays) can, but only with native raid
>> configurations.

> AFAIK:

> 1.  mdadm RAID1 can fix bit rot, so long as one drive has a good block 
> to fix the others.

Yes, but it can't fix silent bit-rot, where incorrect bytes are read
from the drive without the drive noticing. In that case the Kernel has
no way of knowing which bytes are the correct ones, you need some sort
of checksum for that.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#190494

On 12/31/17 09:44, Sven Hartge wrote:
> David Christensen <dpchrist@holgerdanske.com> wrote:
>> On 12/30/17 14:38, Matthew Crews wrote:
> 
>>> The main issue I see with using BTRFS with MDADM is that you lose the
>>> benefit of bit-rot repair. MDADM can't correct bit rot, but
>>> BTRFS-Raid (and ZFS raid arrays) can, but only with native raid
>>> configurations.
> 
>> AFAIK:
> 
>> 1.  mdadm RAID1 can fix bit rot, so long as one drive has a good block
>> to fix the others.
> 
> Yes, but it can't fix silent bit-rot, where incorrect bytes are read
> from the drive without the drive noticing. In that case the Kernel has
> no way of knowing which bytes are the correct ones, you need some sort
> of checksum for that.

My bad -- the only way for md to detect bit-rot is via scrubbing:

     $ man 4 md

     SCRUBBING AND MISMATCHES
     ...
        If check was used, then no action is taken to handle the 
mismatch,  it
        is  simply  recorded.   If  repair  was  used,  then a mismatch 
will be
        repaired in the same way that resync repairs arrays.   For 
RAID5/RAID6
        new parity blocks are written.  For RAID1/RAID10, all but one 
block are
        overwritten with the content of that one block.


I wonder how md picks "that one block"?


I tried to STFW for an md design document -- e.g. explains what file 
structures, data structures, algorithms, etc., are used by md and why -- 
nope.


David

[toc] | [prev] | [next] | [standalone]

#190496

David Christensen <dpchrist@holgerdanske.com> wrote:
> On 12/31/17 09:44, Sven Hartge wrote:
>> David Christensen <dpchrist@holgerdanske.com> wrote:
>>> On 12/30/17 14:38, Matthew Crews wrote:

>>>> The main issue I see with using BTRFS with MDADM is that you lose
>>>> the benefit of bit-rot repair. MDADM can't correct bit rot, but
>>>> BTRFS-Raid (and ZFS raid arrays) can, but only with native raid
>>>> configurations.
>> 
>>> AFAIK:
>> 
>>> 1.  mdadm RAID1 can fix bit rot, so long as one drive has a good
>>> block to fix the others.
 
>> Yes, but it can't fix silent bit-rot, where incorrect bytes are read
>> from the drive without the drive noticing. In that case the Kernel
>> has no way of knowing which bytes are the correct ones, you need some
>> sort of checksum for that.

> My bad -- the only way for md to detect bit-rot is via scrubbing:

>     $ man 4 md

>     SCRUBBING AND MISMATCHES
>     ...
>        If check was used, then no action is taken to handle the mismatch,  it
>        is  simply  recorded.   If  repair  was  used,  then a mismatch will be
>        repaired in the same way that resync repairs arrays.   For RAID5/RAID6
>        new parity blocks are written.  For RAID1/RAID10, all but one block are
>        overwritten with the content of that one block.


> I wonder how md picks "that one block"?

Only if one drives reports an error. Then data from the good block is
used to overwrite the bad block, hoping the drive remaps the sector and
everything is fine again.

If both devices report no error but differing data has been read,
MD-RAID1 can't know which block is good. 

MD-RAID5/6 could calculate all parity combinations and use the data a
majority agrees upon. (I don't know if it does it, though).

I tried looking at the Kernel RAID code, but I must admit: it is all
Esperanto to me, the code is far too low level for me to understand.

S°

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#190520

On 12/31/17 14:45, Sven Hartge wrote:
> David Christensen <dpchrist@holgerdanske.com> wrote:
>>      $ man 4 md
> 
>>      SCRUBBING AND MISMATCHES
>>      ...
>>         If check was used, then no action is taken to handle the mismatch,  it
>>         is  simply  recorded.   If  repair  was  used,  then a mismatch will be
>>         repaired in the same way that resync repairs arrays.   For RAID5/RAID6
>>         new parity blocks are written.  For RAID1/RAID10, all but one block are
>>         overwritten with the content of that one block.
> 
> 
>> I wonder how md picks "that one block"?
> 
> Only if one drives reports an error. Then data from the good block is
> used to overwrite the bad block, hoping the drive remaps the sector and
> everything is fine again.
> 
> If both devices report no error but differing data has been read,
> MD-RAID1 can't know which block is good.
> 
> MD-RAID5/6 could calculate all parity combinations and use the data a
> majority agrees upon. (I don't know if it does it, though).
> 
> I tried looking at the Kernel RAID code, but I must admit: it is all
> Esperanto to me, the code is far too low level for me to understand.

That's why "programming systems product" [1] includes architectural, 
functional, design, construction, etc., documentation.


FreeBSD is better is this regard [2].


David


[1] 
https://www.pearson.com/us/higher-education/program/Brooks-Mythical-Man-Month-The-Essays-on-Software-Engineering-Anniversary-Edition-2nd-Edition/PGM172844.html

[2] 
https://www.pearson.com/us/higher-education/program/Mc-Kusick-Design-and-Implementation-of-the-Free-BSD-Operating-System-The-2nd-Edition/PGM224032.html

[toc] | [prev] | [next] | [standalone]

#190530

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Jan 01, 2018 at 06:01:20PM -0800, David Christensen wrote:
> On 12/31/17 14:45, Sven Hartge wrote:
> >David Christensen <dpchrist@holgerdanske.com> wrote:
> >>     $ man 4 md
> >
> >>     SCRUBBING AND MISMATCHES
> >>     ...
> >>        If check was used, then no action is taken to handle the mismatch,  it
> >>        is  simply  recorded.   If  repair  was  used,  then a mismatch will be
> >>        repaired in the same way that resync repairs arrays.   For RAID5/RAID6
> >>        new parity blocks are written.  For RAID1/RAID10, all but one block are
> >>        overwritten with the content of that one block.
> >
> >
> >>I wonder how md picks "that one block"?
> >
> >Only if one drives reports an error. Then data from the good block is
> >used to overwrite the bad block, hoping the drive remaps the sector and
> >everything is fine again.
> >
> >If both devices report no error but differing data has been read,
> >MD-RAID1 can't know which block is good.
> >
> >MD-RAID5/6 could calculate all parity combinations and use the data a
> >majority agrees upon. (I don't know if it does it, though).
> >
> >I tried looking at the Kernel RAID code, but I must admit: it is all
> >Esperanto to me, the code is far too low level for me to understand.
> 
> That's why "programming systems product" [1] includes architectural,
> functional, design, construction, etc., documentation.
> 
> 
> FreeBSD is better is this regard [2].

Look for documentation in the right shelf. Hint: it's called
Documentation (there are books in there, not nuts and bolts).

As an example: I'm on 4.9.0 (plus some assorted Debian-specific
patches). If I don't want to download the whole kaboodle (although
that would be a good idea), I might be tempted to use the nice
gitweb interface at git.kernel.org:

  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/?h=v4.9

The "tree" view (provided above for your convenience, but you
mith be able to click your way through), you might perhaps find
docs in or around Documentation/md.txt.

Reading source only helps if you have a rough idea on what's going
on.

Cheers
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlpLXwUACgkQBcgs9XrR2kbhgACeJKSDGa3qKVFnu24d7me2YR2v
sGYAn310MNqQUtRUQf3YA4UMziMDx4M6
=vVpK
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#190550

On 01/02/18 02:29, tomas@tuxteam.de wrote:
> 
> On Mon, Jan 01, 2018 at 06:01:20PM -0800, David Christensen wrote:
>> On 12/31/17 14:45, Sven Hartge wrote:
>>> David Christensen <dpchrist@holgerdanske.com> wrote:
>>>>      $ man 4 md
>>>
>>>>      SCRUBBING AND MISMATCHES
>>>>      ...
>>>>         If check was used, then no action is taken to handle the mismatch,  it
>>>>         is  simply  recorded.   If  repair  was  used,  then a mismatch will be
>>>>         repaired in the same way that resync repairs arrays.   For RAID5/RAID6
>>>>         new parity blocks are written.  For RAID1/RAID10, all but one block are
>>>>         overwritten with the content of that one block.
>>>
>>>
>>>> I wonder how md picks "that one block"?
>>>
>>> Only if one drives reports an error. Then data from the good block is
>>> used to overwrite the bad block, hoping the drive remaps the sector and
>>> everything is fine again.
>>>
>>> If both devices report no error but differing data has been read,
>>> MD-RAID1 can't know which block is good.
>>>
>>> MD-RAID5/6 could calculate all parity combinations and use the data a
>>> majority agrees upon. (I don't know if it does it, though).
>>>
>>> I tried looking at the Kernel RAID code, but I must admit: it is all
>>> Esperanto to me, the code is far too low level for me to understand.
>>
>> That's why "programming systems product" [1] includes architectural,
>> functional, design, construction, etc., documentation.
>>
>>
>> FreeBSD is better is this regard [2].
> 
> Look for documentation in the right shelf. Hint: it's called
> Documentation (there are books in there, not nuts and bolts).
> 
> As an example: I'm on 4.9.0 (plus some assorted Debian-specific
> patches). If I don't want to download the whole kaboodle (although
> that would be a good idea), I might be tempted to use the nice
> gitweb interface at git.kernel.org:
> 
>    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/?h=v4.9
> 
> The "tree" view (provided above for your convenience, but you
> mith be able to click your way through), you might perhaps find
> docs in or around Documentation/md.txt.

Yes, I saw that when STFW.  It starts with:

     Boot time assembly of RAID arrays
     ---------------------------------

     You can boot with your md device with the following kernel command
lines:

     for old raid arrays without persistent superblocks:
       md=<md device no.>,<raid level>,<chunk size factor>,<fault 
level>,dev0,dev1,...,devn


That is the crumb under the elephants little toe on its front left foot.


I am looking for a narrative that starts with "We are talking about an 
creature called an 'Elephant'.  This is what the whole animal looks 
like" (and presents a picture).  It should proceed to divide and expand 
that narrative, paying attention to conceptual dependencies, with 
increasing detail (more pictures and diagrams), down to file structures, 
data structures, and algorithms -- e.g. explains the "what" in proper 
English using computer science terms.  And, most importantly: it must 
also explain the "why" at every level.


> Reading source only helps if you have a rough idea on what's going
> on.

Yes.

     "Show me your algorithms, and I will be confused.  Show me your data
     structures, and your algorithms will be obvious."
     -- Edsger W. Dijkstra (?) (I can't can't a find citation)


David

[toc] | [prev] | [next] | [standalone]

#190553

David Christensen wrote:

> You can boot with your md device with the following kernel command
> lines:
> 
> for old raid arrays without persistent superblocks:
> md=<md device no.>,<raid level>,<chunk size factor>,<fault
> level>,dev0,dev1,...,devn

yes and best is you compile raid in, so that boot can be also raided

regards

[toc] | [prev] | [next] | [standalone]

#190558

Le 02/01/2018 à 19:05, deloptes a écrit :
> David Christensen wrote (quoting md.txt from the kernel documentation) :
> 
>> You can boot with your md device with the following kernel command
>> lines:
>>
>> for old raid arrays without persistent superblocks:
>> md=<md device no.>,<raid level>,<chunk size factor>,<fault
>> level>,dev0,dev1,...,devn
> 
> yes and best is you compile raid in, so that boot can be also raided

Best for what ?
Who still uses RAID arrays without persistent superblocks ?
Who still uses RAID assembly by the kernel instead of mdadm ?
All this has beed obsoleted by the superblock format 1.x and the use of 
an initrd or initramfs.

By the way, if you compile md in the kernel, you should also compile all 
necessary host controller and disk drivers in. And expect failure with 
current drivers which do not guarantee that a given disk gets the same 
device name at each boot.

[toc] | [prev] | [next] | [standalone]

#190581

Pascal Hambourg wrote:

> Best for what ?

for booting of raid

> Who still uses RAID arrays without persistent superblocks ?

historic reasons - systems aged 10y+

> Who still uses RAID assembly by the kernel instead of mdadm ?

same as above

> All this has beed obsoleted by the superblock format 1.x and the use of
> an initrd or initramfs.
> 

true :)
man mdadm
"In-kernel autodetect is not recommended for new installations."

> By the way, if you compile md in the kernel, you should also compile all
> necessary host controller and disk drivers in. And expect failure with
> current drivers which do not guarantee that a given disk gets the same
> device name at each boot.

While your statement is true, I personally use UUID (/etc/fstab) and have no
problem with it at all.

Overall summary - you are right - it should not be needed nowdays

regards

[toc] | [prev] | [next] | [standalone]

#190632

Le 03/01/2018 à 00:52, deloptes a écrit :
> Pascal Hambourg wrote:
> 
>> Best for what ?
> 
> for booting of raid

How is it better than using an initramfs ?

>> By the way, if you compile md in the kernel, you should also compile all
>> necessary host controller and disk drivers in. And expect failure with
>> current drivers which do not guarantee that a given disk gets the same
>> device name at each boot.
> 
> While your statement is true, I personally use UUID (/etc/fstab) and have no
> problem with it at all.

The kernel cannot use UUIDs to mount the root filesystem. Using UUIDs 
requires an initramfs.

[toc] | [prev] | [next] | [standalone]

#190643

Pascal Hambourg wrote:

> How is it better than using an initramfs ?
> 
>>> By the way, if you compile md in the kernel, you should also compile all
>>> necessary host controller and disk drivers in. And expect failure with
>>> current drivers which do not guarantee that a given disk gets the same
>>> device name at each boot.
>> 
>> While your statement is true, I personally use UUID (/etc/fstab) and have
>> no problem with it at all.
> 
> The kernel cannot use UUIDs to mount the root filesystem. Using UUIDs
> requires an initramfs.


It is not about not using initramfs, it is about keep old things running.

[toc] | [prev] | [next] | [standalone]

#190667

Le 04/01/2018 à 08:55, deloptes a écrit :
> Pascal Hambourg wrote:
> 
>> How is it better than using an initramfs ?
>>
>>>> By the way, if you compile md in the kernel, you should also compile all
>>>> necessary host controller and disk drivers in. And expect failure with
>>>> current drivers which do not guarantee that a given disk gets the same
>>>> device name at each boot.
>>>
>>> While your statement is true, I personally use UUID (/etc/fstab) and have
>>> no problem with it at all.
>>
>> The kernel cannot use UUIDs to mount the root filesystem. Using UUIDs
>> requires an initramfs.
> 
> It is not about not using initramfs, it is about keep old things running.

If old things are running, then they have already been set up a long 
time ago, and there is not need to tell what's best.

[toc] | [prev] | [next] | [standalone]

#190670

Pascal Hambourg wrote:

> If old things are running, then they have already been set up a long
> time ago, and there is not need to tell what's best.

ok, I reverse the "best" - you are really persistent

[toc] | [prev] | [next] | [standalone]

#190646

Pascal Hambourg wrote:

> The kernel cannot use UUIDs to mount the root filesystem. Using UUIDs
> requires an initramfs.

I forgot to mention that UUID is not meant to be used (only) by the kernel
or the initrd, but by GRUB - to find the boot md - no idea how it works but
it works.

Those machines were running lilo and grub1 and now grub2 - I never looked
into it. There is a process to upgrade kernel and it works fine.
Perhaps you are right that we need to plan doing it "the modern" way, but I
doubt that one would agree to change partition types etc

regards

[toc] | [prev] | [next] | [standalone]

#190573

On 01/02/18 10:05, deloptes wrote:
> David Christensen wrote:
> 
>> You can boot with your md device with the following kernel command
>> lines:
>>
>> for old raid arrays without persistent superblocks:
>> md=<md device no.>,<raid level>,<chunk size factor>,<fault
>> level>,dev0,dev1,...,devn

I did not write that.


This is the second incorrect attribution to myself I've seen in the 
recent past...


David

[toc] | [prev] | [next] | [standalone]

#190579

[Multipart message — attachments visible in raw view] — view raw

On 02/01/18 23:02, David Christensen wrote:
> On 01/02/18 10:05, deloptes wrote:
>> David Christensen wrote:
>>
>>> You can boot with your md device with the following kernel command
>>> lines:
>>>
>>> for old raid arrays without persistent superblocks:
>>> md=<md device no.>,<raid level>,<chunk size factor>,<fault
>>> level>,dev0,dev1,...,devn
>
> I did not write that.
>
>
> This is the second incorrect attribution to myself I've seen in the
> recent past...

Really? It looks like you did.

In message <7603d1fa-88db-25c0-678b-88424fec6426@holgerdanske.com>, I
see four levels of quoting (so five levels of conversation). The message
seems to read that you're quoting tomas@tuxteam.de quoting David
Christensen quoting Sven Hartge quoting David Christensen. About half
way down the message there is an unquoted passage that starts "Yes, I
saw that when I STFW. It starts with" and continues into the above text
("You can boot with").

So, what exactly are you complaining about?

That you didn't write the text originally (i.e. because the author of
the document did)? You may not have authored the text, but you still
wrote into your email (perhaps you copy/pasted it. It's impossible to
know that).

Are you complaining that you didn't write the text as literally shown in
deloptes' email? The bar or characters in the left column of the email
are merely a formatting convention to show which parts of the email are
quoted. You didn't write them, but deloptes added them to demarcate your
text.

Are you complaining that the text wasn't from an email by you, but from
someone else? If so, who do you think it should be attributed to instead?

>
>
> David
>

[toc] | [prev] | [next] | [standalone]

#190582

On Tuesday 02 January 2018 18:45:00 Darac Marjal wrote:

> On 02/01/18 23:02, David Christensen wrote:
> > On 01/02/18 10:05, deloptes wrote:
> >> David Christensen wrote:
> >>> You can boot with your md device with the following kernel command
> >>> lines:
> >>>
> >>> for old raid arrays without persistent superblocks:
> >>> md=<md device no.>,<raid level>,<chunk size factor>,<fault
> >>> level>,dev0,dev1,...,devn
> >
> > I did not write that.
> >
> >
> > This is the second incorrect attribution to myself I've seen in the
> > recent past...
>
> Really? It looks like you did.
>
> In message <7603d1fa-88db-25c0-678b-88424fec6426@holgerdanske.com>, I
> see four levels of quoting (so five levels of conversation). The
> message seems to read that you're quoting tomas@tuxteam.de quoting
> David Christensen quoting Sven Hartge quoting David Christensen. About
> half way down the message there is an unquoted passage that starts
> "Yes, I saw that when I STFW. It starts with" and continues into the
> above text ("You can boot with").
>
> So, what exactly are you complaining about?
>
> That you didn't write the text originally (i.e. because the author of
> the document did)? You may not have authored the text, but you still
> wrote into your email (perhaps you copy/pasted it. It's impossible to
> know that).
>
After 4 or so quote levels, the chances of its having come thru someones 
email agent who doesn't know about proper quoting, or worse yet is so 
used to winslow and the broken quoting its been doing since dos days, 
thinks its doing it right and won't fix it even if called to his 
attention, really is quite astronomical.

After all these years, I only object if something not correct has been 
miss-attributed to me. And its a better than even bet the first person 
to reply to my objection, will do so with an email agent that doesn't do 
it correctly. I swear the damned stuff is self-perpetuating.

Sometimes its not pc to be so friendly you ignore the broken stuff. But 
these lists would get a lot less "friendly" if the perps were called on 
it every time they post.  For a while, but once the offenders fixed 
their agents, I think they would find a new friendliness to a list that 
did enforce it.

Will it actually happen? Chances are I'd have better results offering a 
bridge in Sun City AZ for sale...

> Are you complaining that you didn't write the text as literally shown
> in deloptes' email? The bar or characters in the left column of the
> email are merely a formatting convention to show which parts of the
> email are quoted. You didn't write them, but deloptes added them to
> demarcate your text.
>
> Are you complaining that the text wasn't from an email by you, but
> from someone else? If so, who do you think it should be attributed to
> instead?
>
> > David


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.debian.user

csiph-web