FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 09-02-2012, 07:57 AM
Wouter Verhelst
 
Default Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

On Sat, Sep 01, 2012 at 02:29:20AM +0800, Thomas Goirand wrote:
> On 08/31/2012 11:52 PM, Peter Samuelson wrote:
> > I guess I can understand that you want your /usr to be resizeable
>
> Not only this. I want it on a RAID10 or RAID5 which goes faster than
> my / that is hosted in a slower RAID1.

Okay, this is where you stopped making sense.

RAID1 is *not* slower than RAID5. On the contrary. Think about it:

To write something to RAID1, you need to duplicate your stripes to the
amount of disks you're writing, and just write. It's slower than
single-disk or RAID0 performance (since you need to write more than
once), but other than that you're fine.

In contrast, for every stripe you need to write to RAID5, you need to
- Read all the stripes in a stripe set
- Replace (in memory) the stripe that's being overwritten with the new
data
- Compute the new checksum
- Write out the new checksum and data stripe

The first step can be skipped if the stripe set you need to write to
just happens to be in cache still, but that certainly isn't always the
case (that's why it's called a cache). That also doesn't rule out the
CPU-intensive third step.

If you're doing two-disk RAID1, you're also writing two stripes, but you
don't have to do the first three steps. So for RAID1, you only need to
do the last step. By definition, if you have less work you're going to
be faster.

On read, the RAID implementation can choose which disk to use based on
what its optimization algorithms think is the best option. This means
you'll also get better read performance than with RAID5, where you need
to read the stripe off the disk where it's been written. If you need two
stripes at any particular time with RAID1, you can ask one stripe from
one disk, and the other stripe from another disk in the RAID set. If you
need two stripes at any particular time with RAID5, you need to read
them where they're stored -- and if they happen to be on the same disk,
your performance suffers.

Now it's true that hardware RAID can optimize much of the performance
issues away, but that doesn't mean RAID1 is slower than RAID5. The only
advantage RAID5 has over RAID1 is that it requires less disks, and so it
may be more economical; but speed has nothing to do with it.

--
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a
 
Old 09-02-2012, 10:10 AM
Thomas Goirand
 
Default Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

On 09/02/2012 03:57 PM, Wouter Verhelst wrote:
> On Sat, Sep 01, 2012 at 02:29:20AM +0800, Thomas Goirand wrote:
>> On 08/31/2012 11:52 PM, Peter Samuelson wrote:
>>> I guess I can understand that you want your /usr to be resizeable
>>
>> Not only this. I want it on a RAID10 or RAID5 which goes faster than
>> my / that is hosted in a slower RAID1.
>
> Okay, this is where you stopped making sense.
>
> RAID1 is *not* slower than RAID5. On the contrary. Think about it:

RAID10 really *is* faster than RAID1...

Also, thanks, but I've been using these for years, so I think I know
what I'm talking about!

Thomas


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 50433097.9060709@goirand.fr">http://lists.debian.org/50433097.9060709@goirand.fr
 
Old 09-02-2012, 10:36 AM
Matthew Woodcraft
 
Default Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

Steve Langasek wrote:
> Matthew Woodcraft wrote:

>> Debian has supported booting from md RAID without using an initramfs for
>> a very long time.

> True but misleading. LILO supported it because it hard-coded the block list
> of the kernel and initrd at install time. GRUB1 never supported any RAID
> except for RAID1, as far as I'm aware. GRUB2 has supported RAID5 since
> ~2008, but has only been used as the default boot loader in Debian since
> 2011; prior to that the installer would select the best bootloader for the
> chosen disk layout - but grub2 was sufficiently experimental at that point
> that no one who actually cared about their data would be using it.

The relevant information I was supplying (to Wouter) is that there are
currently systems using md+LVM but not an initramfs.

(But I don't think what I wrote is misleading. Yes, that is how LILO
worked. Yes, I am thinking of RAID 1, as was Thomas; around here that's
an unsurprising choice for the disks holding the operating system.)


>> GRUB2 can boot from LVM or a separate /boot, but in any case
>> risk-averse people might choose to avoid root-on-LVM; this is one of
>> the reasons for putting /usr on a separate filesystem in the first
>> place.

> I wouldn't call this being risk averse, I would call it being *bad* at
> risk assessment / risk management. All the interesting data needed for
> running the system is on a filesystem other than the root filesystem
> in that case. If you actually think LVM isn't safe, you shouldn't be
> using it for /usr (and /var). If you think it is safe, you should have
> / on it as well and, if necessary, allocate a separate /boot partition
> for the bootloader.

The main risk I'm concerned about is of the system failing to boot
without tiresome manual intervention, rather than difficulties once it's
up and running.

But of course there have in the past been LVM bugs which showed up only
if the root was on LVM.


> The system I'm sending this email from would fail to boot if separate
> /usr without initramfs stops being supported.

>> Can you please elaborate on why that is?

Only because it doesn't currently use an initramfs.

If I end up having to make a choice in the near future, I imagine I'll
move /usr off LVM rather than start to use an initramfs.

I expect the time will come when I feel comfortable that for a system
running testing I can use Debian's initramfs and expect everything to
Just Work. But that time hadn't arrived the last time I got new disks,
and looking at the initramfs-tools bug page I see two open Important
bugs, each about a year old, about the md+LVM combination. So I'm not
tempted to switch in the near future.

(In contrast, for systems running stable I do use Debian's initramfs.
Though I've had boot failure due to the initramfs failing to update as
recently as the etch -> squeeze upgrades, with nothing more exotic
involved than a kernel from backports.)


Anyway, when Debian comes to decide what to do about the subject of this
thread, I suggest that the following option is worth considering:

- a system without /usr mounted is no longer expected to be generally
useful for 'rescue' purposes;

- a system without /usr mounted is still expected to be capable of
mounting a /usr filesystem held on local disks.

-M-


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120902103642.GA9843@golux.woodcraft.me.uk">http://lists.debian.org/20120902103642.GA9843@golux.woodcraft.me.uk
 
Old 09-02-2012, 11:31 AM
The Wanderer
 
Default Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

On 09/02/2012 03:57 AM, Wouter Verhelst wrote:


On Sat, Sep 01, 2012 at 02:29:20AM +0800, Thomas Goirand wrote:


On 08/31/2012 11:52 PM, Peter Samuelson wrote:


I guess I can understand that you want your /usr to be resizeable


Not only this. I want it on a RAID10 or RAID5 which goes faster than my /
that is hosted in a slower RAID1.


Okay, this is where you stopped making sense.

RAID1 is *not* slower than RAID5. On the contrary. Think about it:


I interpreted that statement as meaning that the RAID1 was hosted on slower
hardware, and therefore was slower overall.

--
The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Every time you let somebody set a limit they start moving it.
- LiveJournal user antonia_tiger


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 504343AB.5020305@fastmail.fm">http://lists.debian.org/504343AB.5020305@fastmail.fm
 
Old 09-02-2012, 01:08 PM
Vincent Bernat
 
Default Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

❦ 2 septembre 2012 12:10 CEST, Thomas Goirand <thomas@goirand.fr>*:

>>> Not only this. I want it on a RAID10 or RAID5 which goes faster than
>>> my / that is hosted in a slower RAID1.
>>
>> Okay, this is where you stopped making sense.
>>
>> RAID1 is *not* slower than RAID5. On the contrary. Think about it:
>
> RAID10 really *is* faster than RAID1...

That's amazing how you can make every conversation goes into infinite
loops.

Put your / on RAID10 too and your "problem" is solved.
--
printk("Entering UltraSMPenguin Mode...
");
2.2.16 /usr/src/linux/arch/sparc64/kernel/smp.c
 
Old 09-03-2012, 03:54 PM
Serge
 
Default Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

2012/8/31 Simon McVittie wrote:

>> thus it reduces flexibility, breaking use cases, that were working before.
>
> Please name them.

I was thinking about lots of custom mount options that were easy to set up
and were working for decades with normal root partition, but will now need
tricky hacks to adopt them for initramfs.

But there're more:
* ability to easily edit content of root partition and put some additional
software to mount /usr (much easier than making changes to initramfs)
* ability to boot with separate /usr without initramfs (people still use that)
* recover from epic disaster
(https://github.com/MrMEEE/bumblebee/commit/a047be85247755cdbe0acce6f1dafc8beb84f2ac)
* log in locally as root and check/fix things having non-mountable usr

There're some minor issues, not that important, but still:
* larger initramfs adds problems for embedded systems
* update of binaries in root partition does not update binaries in initramfs

You may think that none of that really needed. "You don't need it" is a very
popular argument in such cases. But it never works, because I can answer that
computers and mobile phones are not really needed as well, mankind existed
without them for thousands of years. But it does not mean that we should
throw them out of window. We already had all these things before, it's
pointless to throw them out for nothing.

> "The ability to mount my /usr requires user interaction via a UI in /usr"
> doesn't count, because it has never worked, and is logically impossible.

Yes, that's what I'm talking about. It was not solved before, and it's still
not solved. New initramfs approach solves nothing. It just turns one problem
into another one, requires additional work and adds slots for new bugs.

> If a filesystem is not on the critical path to boot to the point where
> you can get the prerequisites for mounting filesystems, you don't need
> to mount it from the initramfs. (For instance, /srv isn't needed until
> later.)

You can't be sure about that. It could be that on some system the stuff needed
to mount /usr was on /srv partition. And it worked because /srv was put before
/usr in /etc/fstab. In "historical approach" it works, but not in
"initramfs approach".

--
Serge


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/CAOVenEqPsA=c2p3PJd3swiE=GLKMuimKwdDix2fSmxxnrx8NX Q@mail.gmail.com
 
Old 09-03-2012, 04:12 PM
 
Default Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

On Sep 03, Serge <sergemdev@gmail.com> wrote:

> * ability to easily edit content of root partition and put some additional
> software to mount /usr
Can you show some actual real life examples?

> (much easier than making changes to initramfs)
And anyway, adding programs to the initramfs is as trivial as dropping
an hook script in /etc/initramfs-tools/, so this is a very weak argument.

> * ability to boot with separate /usr without initramfs (people still use that)
Just because somebody does it it does not mean that it is worth
supporting.

> * recover from epic disaster
> (https://github.com/MrMEEE/bumblebee/commit/a047be85247755cdbe0acce6f1dafc8beb84f2ac)
> * log in locally as root and check/fix things having non-mountable usr
You can do this as well from the initramfs or an on-disk recovery image
like the one installed by the grml-rescueboot package.

> * larger initramfs adds problems for embedded systems
Please provide some actual data which shows how this would be a problem
and on which embedded systems.

> * update of binaries in root partition does not update binaries in initramfs
Nothing new here.

> Yes, that's what I'm talking about. It was not solved before, and it's still
> not solved. New initramfs approach solves nothing. It just turns one problem
> into another one, requires additional work and adds slots for new bugs.
You got it backwards: mounting /usr in the initramfs actually fixes the
problems with a standalone /usr, and the work needed is minimal because
we can reuse the code which is available to mount /.

> You can't be sure about that. It could be that on some system the stuff needed
> to mount /usr was on /srv partition. And it worked because /srv was put before
> /usr in /etc/fstab. In "historical approach" it works, but not in
> "initramfs approach".
Please show some real world examples of such a configuration.

--
ciao,
Marco
 
Old 09-04-2012, 02:44 PM
Martin Wuertele
 
Default Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

* Marco d'Itri <md@Linux.IT> [2012-09-03 18:13]:

> On Sep 03, Serge <sergemdev@gmail.com> wrote:
>
> > * ability to easily edit content of root partition and put some additional
> > software to mount /usr
> Can you show some actual real life examples?
>
> > (much easier than making changes to initramfs)
> And anyway, adding programs to the initramfs is as trivial as dropping
> an hook script in /etc/initramfs-tools/, so this is a very weak argument.

Having used non-initramfs systems for years after it was recommended I
meanwhile switched to initramfs as you can embed quite a lot of useful
recovery tools with simple hooks so you can use them even when / and
/usr have issues, as long as /boot can boot into the initramfs.

> > * larger initramfs adds problems for embedded systems
> Please provide some actual data which shows how this would be a problem
> and on which embedded systems.

Embedded systems without initramfs up to my experience handle stuff
differently anyways (and I haven't seen one installation with / and /usr
on different filesystems) and I therefore don't expect any impact on
those systems.

> > You can't be sure about that. It could be that on some system the stuff needed
> > to mount /usr was on /srv partition. And it worked because /srv was put before
> > /usr in /etc/fstab. In "historical approach" it works, but not in
> > "initramfs approach".
> Please show some real world examples of such a configuration.

So far I haven't seen any convincing real world examples and I spent
some time looking. I'm curious as well if there are any corner cases
that would require adding hints to the release notes.

Yours Martin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120904144421.GA10872@anguilla.debian.or.at">http ://lists.debian.org/20120904144421.GA10872@anguilla.debian.or.at
 

Thread Tools




All times are GMT. The time now is 07:35 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org