Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.hardware > #3077 > unrolled thread
| Started by | Haines Brown <haines@engels.histomat.net> |
|---|---|
| First post | 2016-05-26 13:16 -0400 |
| Last post | 2017-02-13 08:12 +0100 |
| Articles | 20 on this page of 72 — 16 participants |
Back to article view | Back to comp.os.linux.hardware
maximum number of partitions Haines Brown <haines@engels.histomat.net> - 2016-05-26 13:16 -0400
Re: maximum number of partitions "Carlos E.R." <robin_listas@invalid.es> - 2016-05-26 20:22 +0200
Re: maximum number of partitions Haines Brown <haines@engels.histomat.net> - 2016-05-26 16:02 -0400
Re: maximum number of partitions Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> - 2016-05-26 21:02 +0000
Re: maximum number of partitions "Carlos E.R." <robin_listas@invalid.es> - 2016-05-27 00:36 +0200
Re: maximum number of partitions Haines Brown <haines@engels.histomat.net> - 2016-05-27 07:08 -0400
Re: maximum number of partitions floyd@apaflo.com (Floyd L. Davidson) - 2016-05-27 04:03 -0800
Re: maximum number of partitions Haines Brown <haines@engels.histomat.net> - 2016-05-27 09:25 -0400
Re: maximum number of partitions floyd@apaflo.com (Floyd L. Davidson) - 2016-05-27 05:53 -0800
Re: maximum number of partitions Haines Brown <haines@engels.histomat.net> - 2016-05-27 12:48 -0400
Re: maximum number of partitions "Carlos E.R." <robin_listas@invalid.es> - 2016-05-27 14:50 +0200
Re: maximum number of partitions Vilmos Soti <vilmos@soti.ca> - 2016-05-26 12:40 -0700
Re: maximum number of partitions Marc Haber <mh+usenetspam1118@zugschl.us> - 2016-05-26 22:29 +0200
LVM [was: maximum number of partitions] Haines Brown <haines@engels.histomat.net> - 2016-05-27 07:44 -0400
Re: LVM [was: maximum number of partitions] Marc Haber <mh+usenetspam1118@zugschl.us> - 2016-05-27 18:07 +0200
Re: maximum number of partitions Richard Kettlewell <rjk@greenend.org.uk> - 2016-05-26 22:27 +0100
Re: maximum number of partitions Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> - 2016-05-27 06:05 +0000
Re: maximum number of partitions Richard Kettlewell <rjk@greenend.org.uk> - 2016-05-27 08:36 +0100
Re: maximum number of partitions "Carlos E.R." <robin_listas@invalid.es> - 2016-05-27 12:17 +0200
Re: maximum number of partitions Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> - 2016-05-27 18:49 +0000
Re: maximum number of partitions Robert Nichols <SEE_SIGNATURE@localhost.localdomain.invalid> - 2016-05-27 19:08 -0500
Re: maximum number of partitions Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> - 2016-05-28 07:11 +0000
Re: maximum number of partitions Robert Nichols <SEE_SIGNATURE@localhost.localdomain.invalid> - 2016-05-28 09:22 -0500
Re: maximum number of partitions Aragorn <thorongil@telenet.be.invalid> - 2016-05-27 10:07 +0200
Re: maximum number of partitions Marc Haber <mh+usenetspam1118@zugschl.us> - 2016-05-27 18:07 +0200
Re: maximum number of partitions "Carlos E.R." <robin_listas@invalid.es> - 2016-05-27 20:30 +0200
Re: maximum number of partitions Marc Haber <mh+usenetspam1118@zugschl.us> - 2016-05-28 00:05 +0200
Re: maximum number of partitions "Carlos E.R." <robin_listas@invalid.es> - 2016-05-28 04:45 +0200
Re: maximum number of partitions Marc Haber <mh+usenetspam1118@zugschl.us> - 2016-05-28 07:26 +0200
Re: maximum number of partitions Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> - 2016-05-28 07:15 +0000
Re: maximum number of partitions Marc Haber <mh+usenetspam1118@zugschl.us> - 2016-05-28 10:25 +0200
Re: maximum number of partitions Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> - 2016-05-28 11:14 +0000
Re: maximum number of partitions Marc Haber <mh+usenetspam1118@zugschl.us> - 2016-05-28 13:52 +0200
Re: maximum number of partitions Aragorn <thorongil@telenet.be.invalid> - 2016-05-28 18:46 +0200
Re: maximum number of partitions Marc Haber <mh+usenetspam1118@zugschl.us> - 2016-05-28 19:57 +0200
Re: maximum number of partitions Aragorn <thorongil@telenet.be.invalid> - 2016-05-28 20:15 +0200
Re: maximum number of partitions Bobbie Sellers <bliss-sf4ever@dslextreme.com> - 2016-05-28 12:04 -0700
Re: maximum number of partitions Marc Haber <mh+usenetspam1118@zugschl.us> - 2016-05-28 22:47 +0200
Re: maximum number of partitions Aragorn <thorongil@telenet.be.invalid> - 2016-05-29 07:36 +0200
Re: maximum number of partitions "Carlos E.R." <robin_listas@invalid.es> - 2016-05-29 13:48 +0200
Re: maximum number of partitions Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> - 2016-06-04 09:50 +0200
Re: maximum number of partitions Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> - 2016-06-05 10:10 +0000
Re: maximum number of partitions Aragorn <thorongil@telenet.be.invalid> - 2016-06-05 14:31 +0200
Re: maximum number of partitions Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> - 2016-06-05 13:53 +0000
Re: maximum number of partitions Aragorn <thorongil@telenet.be.invalid> - 2016-06-05 16:18 +0200
Re: maximum number of partitions Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> - 2016-06-05 18:53 +0000
Re: maximum number of partitions Scott Hemphill <hemphill@hemphills.net> - 2016-06-05 17:58 -0400
Re: maximum number of partitions Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> - 2016-06-06 14:09 +0000
Re: maximum number of partitions Scott Hemphill <hemphill@hemphills.net> - 2016-06-06 10:32 -0400
Re: maximum number of partitions Aragorn <thorongil@telenet.be.invalid> - 2016-06-06 16:48 +0200
Re: maximum number of partitions Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> - 2016-06-08 22:23 +0200
Re: maximum number of partitions Richard Kettlewell <rjk@greenend.org.uk> - 2016-06-06 15:55 +0100
Re: maximum number of partitions Aragorn <thorongil@telenet.be.invalid> - 2016-06-06 17:41 +0200
Re: maximum number of partitions Richard Kettlewell <rjk@greenend.org.uk> - 2016-06-06 17:23 +0100
Re: maximum number of partitions "Carlos E.R." <robin_listas@invalid.es> - 2016-06-06 22:36 +0200
Re: maximum number of partitions Richard Kettlewell <rjk@greenend.org.uk> - 2016-06-06 21:51 +0100
Re: maximum number of partitions Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> - 2016-06-07 04:54 +0000
Re: maximum number of partitions Richard Kettlewell <rjk@greenend.org.uk> - 2016-06-07 08:43 +0100
Re: maximum number of partitions Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> - 2016-06-07 19:04 +0000
Re: maximum number of partitions Richard Kettlewell <rjk@greenend.org.uk> - 2016-06-07 20:30 +0100
Re: maximum number of partitions Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> - 2016-06-08 07:08 +0000
Re: maximum number of partitions Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> - 2016-06-06 15:50 +0000
Re: maximum number of partitions "Carlos E.R." <robin_listas@invalid.es> - 2016-06-05 16:03 +0200
Re: maximum number of partitions noSpam@gmail.com - 2016-07-18 18:57 +0000
Re: maximum number of partitions "Carlos E.R." <robin_listas@invalid.es> - 2016-05-28 17:10 +0200
Re: maximum number of partitions Richard Kettlewell <rjk@greenend.org.uk> - 2016-05-28 18:07 +0100
Re: maximum number of partitions "Carlos E.R." <robin_listas@invalid.es> - 2016-05-28 21:33 +0200
Re: maximum number of partitions novinhael@gmail.com - 2017-02-07 18:10 -0800
Re: maximum number of partitions Robert Nichols <SEE_SIGNATURE@localhost.localdomain.invalid> - 2017-02-08 07:58 -0600
Re: maximum number of partitions faeychild <faeychild@nomail.afraid.org> - 2017-02-13 15:23 +1100
Re: maximum number of partitions "Carlos E. R." <robin_listas@invalid.es> - 2017-02-13 08:04 +0100
Re: maximum number of partitions "Carlos E. R." <robin_listas@invalid.es> - 2017-02-13 08:12 +0100
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> |
|---|---|
| Date | 2016-06-04 09:50 +0200 |
| Message-ID | <niu17u$b8c$2@saria.nerim.net> |
| In reply to | #3109 |
Henrik Carlqvist a écrit : > > Yes, but my point in defending the OP choice of having many partitions is > that when you get a broken file system you will get it on a file system > which was written to. If this happens to your only partition you will > have a harder time to run fsck. Why ? fsck cares about filesystems, not partitions. One partition does not mean one filesystem.
[toc] | [prev] | [next] | [standalone]
| From | Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> |
|---|---|
| Date | 2016-06-05 10:10 +0000 |
| Message-ID | <nj0tqi$6tc$1@dont-email.me> |
| In reply to | #3133 |
On Sat, 04 Jun 2016 09:50:22 +0200, Pascal Hambourg wrote: > Henrik Carlqvist a écrit : >> my point in defending the OP choice of having many partitions is that >> when you get a broken file system you will get it on a file system >> which was written to. If this happens to your only partition you will >> have a harder time to run fsck. > > Why ? > fsck cares about filesystems, not partitions. One partition does not > mean one filesystem. Yes, as long as you have different file systems on different partitions or on different logical volumes you avoid this problem. However, using LVM to create only one single file system knowing that you will be able to resize it if needed in the future might seem like a simple approach to many. But using LVM that way will give you fsck disadvantages as well as the disadvantages from havint an unimportant directory tree filled up affecting more important directory trees. But are you with LVM really able to have multiple logical volumes if you only have one single partition? I thought that you would need at least one partition for every logical volume and that you would need one logical volume for each file system? regards Henrik -- The address in the header is only to prevent spam. My real address is: hc351(at)poolhem.se Examples of addresses which go to spammers: root@localhost postmaster@localhost
[toc] | [prev] | [next] | [standalone]
| From | Aragorn <thorongil@telenet.be.invalid> |
|---|---|
| Date | 2016-06-05 14:31 +0200 |
| Message-ID | <nj1626$43l$1@dont-email.me> |
| In reply to | #3136 |
On Sunday 05 Jun 2016 12:10, Henrik Carlqvist conveyed the following to
comp.os.linux.hardware...
> On Sat, 04 Jun 2016 09:50:22 +0200, Pascal Hambourg wrote:
>
>> Henrik Carlqvist a écrit :
>>> my point in defending the OP choice of having many partitions is
>>> that when you get a broken file system you will get it on a file
>>> system which was written to. If this happens to your only partition
>>> you will have a harder time to run fsck.
>>
>> Why ?
>> fsck cares about filesystems, not partitions. One partition does not
>> mean one filesystem.
>
> Yes, as long as you have different file systems on different
> partitions or on different logical volumes you avoid this problem.
>
> However, using LVM to create only one single file system knowing that
> you will be able to resize it if needed in the future might seem like
> a simple approach to many. But using LVM that way will give you fsck
> disadvantages as well as the disadvantages from havint an unimportant
> directory tree filled up affecting more important directory trees.
>
> But are you with LVM really able to have multiple logical volumes if
> you only have one single partition?
Yes, of course. That's the whole idea.
> I thought that you would need at least one partition for every logical
> volume and that you would need one logical volume for each file
> system?
No... The first step is to create a physical volume with
/sbin/pvcreate. This can span an entire hard disk, so that the hard
disk doesn't even need to have a partition table (although it can), or
you can choose a real partition as the physical volume. Using an entire
hard disk as the physical volume without that there is a partition table
is of course not recommended for system disks.
Then, within the physical volume, you create logical volumes with
/sbin/lvcreate. Logical volumes can be contiguous or discontiguous.
Then, you create a filesystem on each created logical volume by using
the filesystem creation tools for the filesystem you wish to have on
there. You can use different filesystem types and different block
sizes, et al, just as you would with normal partitions.
At boot time, the system scans the hard disks with /sbin/lvscan, invoked
via the boot scripts.
An alternative to using the traditional logical volumes is a filesystem
with a built-in volume manager, such as btrfs or Solaris' ZFS. Those
filesystems don't use a separate step for creating the individual
volumes, because they support multiple filesystem roots, and so you
simply create the parent filesystem, and then you create separate
volumes when creating directories as you go along.
So for instance, you create a partition and create a btrfs filesystem on
it, and you intend to use that partition as your root filesystem. Then,
you create a directory /home within the already formatted filesystem,
and you tell the filesystem that /home must be a separate subvolume.
Every modern distribution will come with the tools already installed,
and by consequence, also with the man pages for those tools. If you're
interested in the subject, then I recommend perusing those man pages,
because they will already be on your system anyway, so you won't have to
install them separately. ;)
--
= Aragorn =
http://www.linuxcounter.net - registrant #223157
[toc] | [prev] | [next] | [standalone]
| From | Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> |
|---|---|
| Date | 2016-06-05 13:53 +0000 |
| Message-ID | <nj1at0$i32$1@dont-email.me> |
| In reply to | #3137 |
On Sun, 05 Jun 2016 14:31:02 +0200, Aragorn wrote: > On Sunday 05 Jun 2016 12:10, Henrik Carlqvist conveyed the following to > comp.os.linux.hardware... >> But are you with LVM really able to have multiple logical volumes if >> you only have one single partition? > Yes, of course. That's the whole idea. > >> I thought that you would need at least one partition for every logical >> volume and that you would need one logical volume for each file system? > > No... The first step is to create a physical volume with > /sbin/pvcreate. This can span an entire hard disk, so that the hard > disk doesn't even need to have a partition table (although it can), or > you can choose a real partition as the physical volume. Using an entire > hard disk as the physical volume without that there is a partition table > is of course not recommended for system disks. > > Then, within the physical volume, you create logical volumes with > /sbin/lvcreate. Logical volumes can be contiguous or discontiguous. > Then, you create a filesystem on each created logical volume > If you're interested in the subject, then I recommend perusing those > man pages, because they will already be on your system anyway, so you > won't have to install them separately. ;) Looking at the man-page of lvcreate on my Slackware 13.1 system it says: -8<--------------------------------------------- lvcreate creates a new logical volume in a volume group ( see vgcre- ate(8), vgchange(8) ) by allocating logical extents from the free phys- ical extent pool of that volume group. -8<--------------------------------------------- It is not clear by the man page what those "physical extents" are, but the the first image on https://en.wikipedia.org/wiki/Logical_Volume_Manager_%28Linux%29 explaining "Various elements ofthe LVM" seems to indicate that a Volume Group might consist of any number of Physical Volumes and that each Physical Volume has a number of Physical Partitions. Then those partitions seemt to be used for Logical Volumes. The text next to that image also says that "Logical Volumes can be resized online by concatenating extents onto them." From the image it seems as if each extent is a Physical Partition. The man-page of lvcreate also has an example: -8<--------------------------- "lvcreate -L 64M -n lvol1 vg00 /dev/sda:0-7 /dev/sdb:0-7" creates a linear logical volume "vg00/lvol1" using physical extents /dev/sda:0-7 and /dev/sdb:0-7 for allocation of extents. -8<--------------------------- Those physical extents /dev/sda:0-7 and /dev/sdb:0-7 seem just like partitions to me. But I have no experience from LVM myself, the above is only what I have tried to read in man pages and find with google. regards Henrik -- The address in the header is only to prevent spam. My real address is: hc351(at)poolhem.se Examples of addresses which go to spammers: root@localhost postmaster@localhost
[toc] | [prev] | [next] | [standalone]
| From | Aragorn <thorongil@telenet.be.invalid> |
|---|---|
| Date | 2016-06-05 16:18 +0200 |
| Message-ID | <nj1ccf$96q$1@dont-email.me> |
| In reply to | #3138 |
On Sunday 05 Jun 2016 15:53, Henrik Carlqvist conveyed the following to
comp.os.linux.hardware...
> On Sun, 05 Jun 2016 14:31:02 +0200, Aragorn wrote:
>
>> On Sunday 05 Jun 2016 12:10, Henrik Carlqvist conveyed the following
>> to comp.os.linux.hardware...
>>> But are you with LVM really able to have multiple logical volumes if
>>> you only have one single partition?
>
>> Yes, of course. That's the whole idea.
>>
>>> I thought that you would need at least one partition for every
>>> logical volume and that you would need one logical volume for each
>>> file system?
>>
>> No... The first step is to create a physical volume with
>> /sbin/pvcreate. This can span an entire hard disk, so that the hard
>> disk doesn't even need to have a partition table (although it can),
>> or you can choose a real partition as the physical volume. Using an
>> entire hard disk as the physical volume without that there is a
>> partition table is of course not recommended for system disks.
>>
>> Then, within the physical volume, you create logical volumes with
>> /sbin/lvcreate. Logical volumes can be contiguous or discontiguous.
>> Then, you create a filesystem on each created logical volume
>
>> If you're interested in the subject, then I recommend perusing those
>> man pages, because they will already be on your system anyway, so you
>> won't have to install them separately. ;)
>
> Looking at the man-page of lvcreate on my Slackware 13.1 system it
> says:
>
> -8<---------------------------------------------
> lvcreate creates a new logical volume in a volume group ( see
> vgcre- ate(8), vgchange(8) ) by allocating logical extents from the
> free phys-
> ical extent pool of that volume group.
> -8<---------------------------------------------
Yep, I forgot to mention vgcreate. You can have multiple volume groups,
each of them containing multiple logical volumes. For a simple home-
based desktop system, having only one volume group would normally cut
it, but for servers, having multiple volume groups for administrative
purposes could be very interesting.
> It is not clear by the man page what those "physical extents" are, but
> the the first image on
> https://en.wikipedia.org/wiki/Logical_Volume_Manager_%28Linux%29
> explaining "Various elements ofthe LVM" seems to indicate that a
> Volume Group might consist of any number of Physical Volumes and that
> each Physical Volume has a number of Physical Partitions. Then those
> partitions seemt to be used for Logical Volumes. The text next to that
> image also says that "Logical Volumes can be resized online by
> concatenating extents onto them." From the image it seems as if each
> extent is a Physical Partition.
>
> The man-page of lvcreate also has an example:
> -8<---------------------------
> "lvcreate -L 64M -n lvol1 vg00 /dev/sda:0-7 /dev/sdb:0-7"
> creates a linear logical volume "vg00/lvol1" using physical
> extents /dev/sda:0-7 and /dev/sdb:0-7 for allocation of extents.
> -8<---------------------------
>
> Those physical extents /dev/sda:0-7 and /dev/sdb:0-7 seem just like
> partitions to me.
Physical extents can be disk blocks, hard disks, hard disk partitions or
even logical volumes, depending on the context.
It's an abstraction layer above the physical partitioning layout. A
single logical volume could for instance span two complete hard disks
plus a couple of partitions on yet a third hard disk.
A common scenario for a home-based desktop workstation with a single
hard disk could for instance be to create a separate /boot partition and
one big partition covering the rest of the system ─ you will need to
boot such a system using an initramfs with LVM support, of course, but
dracut can take care of that.
Then, you preparate the big partition with pvcreate, and then you create
a single volume group within that with vgcreate. Next, you create
logical volumes within that volume group while still leaving an amount
of unallocated space on your hard disk, and you start creating
filesystems on the logical volumes, starting with the root filesystem,
and then creating directories to mount the individual filesystems on.
Now, if at some point later on you find that a particular filesystem is
getting too small, then you can extend the logical volume with
blocks/extents from the unallocated part of the physical partition, and
then all you need to do is grow the filesystem so that it makes use of
those added blocks/extents.
LVM also allows you to create snapshots, move the snapshots, concatenate
logical volumes into a new volume, et al.
--
= Aragorn =
http://www.linuxcounter.net - registrant #223157
[toc] | [prev] | [next] | [standalone]
| From | Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> |
|---|---|
| Date | 2016-06-05 18:53 +0000 |
| Message-ID | <nj1sei$iho$1@dont-email.me> |
| In reply to | #3140 |
On Sun, 05 Jun 2016 16:18:55 +0200, Aragorn wrote: > Physical extents can be disk blocks, hard disks, hard disk partitions or > even logical volumes, depending on the context. Thanks for the explanation! regards Henrik -- The address in the header is only to prevent spam. My real address is: hc351(at)poolhem.se Examples of addresses which go to spammers: root@localhost postmaster@localhost
[toc] | [prev] | [next] | [standalone]
| From | Scott Hemphill <hemphill@hemphills.net> |
|---|---|
| Date | 2016-06-05 17:58 -0400 |
| Message-ID | <87lh2j5mdw.fsf@hemphills.net> |
| In reply to | #3141 |
Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> writes: > On Sun, 05 Jun 2016 16:18:55 +0200, Aragorn wrote: >> Physical extents can be disk blocks, hard disks, hard disk partitions or >> even logical volumes, depending on the context. > > Thanks for the explanation! I would normally think of physical extents as the allocation unit for a volume group. When you are creating a volume group you can choose how big you want the physical extents to be. As a practical example of volume management, I recently had a system that was running out of space on the root volume group, which contained a single logical volume with the root filesystem on it. (This filesystem contained all the normal system files including /home.) The system also had a database volume group that was fine. The root volume group was 40G in size. I had another 80GB drive hotswap-added to the system, and caused the kernel to rescan the SCSI bus so I could see the drive. I created two new 40GB partitions, because I knew that I would want to add the 40GB to the root volume group, and I was holding the other 40GB in reserve. I used vgextend to add the space on the new partition to the root volume group. I then used lvextend to both add the space to the root logical volume and resize the ext4 root filesystem. Voila! I now had an 80GB root filesystem without rebooting a production machine! Scott -- Scott Hemphill hemphill@alumni.caltech.edu "This isn't flying. This is falling, with style." -- Buzz Lightyear
[toc] | [prev] | [next] | [standalone]
| From | Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> |
|---|---|
| Date | 2016-06-06 14:09 +0000 |
| Message-ID | <nj4069$vl9$1@dont-email.me> |
| In reply to | #3142 |
On Sun, 05 Jun 2016 17:58:03 -0400, Scott Hemphill wrote: > I would normally think of physical extents as the allocation unit for a > volume group. Thanks also for this explanation and the example which followed! > Voila! I now had an 80GB root filesystem without rebooting > a production machine! Yes, I see the point with being able to easily expand file systems on logical volumes. But IMHO the drawback of relying on this functionality is that it might tempt you to place almost your entire directory tree on a single file system. The importance of having a small root file system might not be as important today with journaled file systems as it once used to be, but I still think that it feels safe to know that I will most likely be able to boot to single user mode and fsck all other file systems in case of power outage. Also, when different directory trees gets filled up to 100% different kind of bad stuff will happen. If /var/log gets filled up you will no longer get any logs... If /home gets filled up you will no longer be able to start any new X applications... If / gets filled up you will no longer be able to mount or umount any file systems. If all your directory trees lives in the same file system and that file system gets filled up all bad stuff will happen at once. My own / partition is 510 MB and that also includes the /boot directory. My biggest partition is /var/images at 101G where I keep some iso- and hd- images I use with qemu. regards Henrik -- The address in the header is only to prevent spam. My real address is: hc351(at)poolhem.se Examples of addresses which go to spammers: root@localhost postmaster@localhost
[toc] | [prev] | [next] | [standalone]
| From | Scott Hemphill <hemphill@hemphills.net> |
|---|---|
| Date | 2016-06-06 10:32 -0400 |
| Message-ID | <87h9d65qxb.fsf@hemphills.net> |
| In reply to | #3143 |
Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> writes: > On Sun, 05 Jun 2016 17:58:03 -0400, Scott Hemphill wrote: >> I would normally think of physical extents as the allocation unit for a >> volume group. > > Thanks also for this explanation and the example which followed! > >> Voila! I now had an 80GB root filesystem without rebooting >> a production machine! > > Yes, I see the point with being able to easily expand file systems on > logical volumes. But IMHO the drawback of relying on this functionality > is that it might tempt you to place almost your entire directory tree on > a single file system. Indeed, this is what I have done with this system. But I have to manage multiple systems, and this simplifies management. > The importance of having a small root file system might not be as > important today with journaled file systems as it once used to be, but I > still think that it feels safe to know that I will most likely be able to > boot to single user mode and fsck all other file systems in case of power > outage. I am not so worried about this case. The system is running on a UPS, and if necessary, I can restore the whole system from backup. Also, the hard drives I mentioned are actually virtual drives allocated as pieces of a large RAID-6 array. > Also, when different directory trees gets filled up to 100% different > kind of bad stuff will happen. If /var/log gets filled up you will no > longer get any logs... If /home gets filled up you will no longer be able > to start any new X applications... If / gets filled up you will no longer > be able to mount or umount any file systems. This would be more of a concern to me if my system were a general purpose timesharing system with multiple users. In this case, I am the only user, and the system serves just one purpose. I ran out of space because I changed the way I do offsite backups. > If all your directory trees lives in the same file system and that file > system gets filled up all bad stuff will happen at once. > > My own / partition is 510 MB and that also includes the /boot directory. > My biggest partition is /var/images at 101G where I keep some iso- and hd- > images I use with qemu. I think we all have to balance risks with the costs of management, and we will come up with different solutions based on our needs. Scott -- Scott Hemphill hemphill@alumni.caltech.edu "This isn't flying. This is falling, with style." -- Buzz Lightyear
[toc] | [prev] | [next] | [standalone]
| From | Aragorn <thorongil@telenet.be.invalid> |
|---|---|
| Date | 2016-06-06 16:48 +0200 |
| Message-ID | <nj42fd$dfa$1@dont-email.me> |
| In reply to | #3143 |
On Monday 06 Jun 2016 16:09, Henrik Carlqvist conveyed the following to
comp.os.linux.hardware...
> On Sun, 05 Jun 2016 17:58:03 -0400, Scott Hemphill wrote:
>> I would normally think of physical extents as the allocation unit for
>> a volume group.
>
> Thanks also for this explanation and the example which followed!
>
>> Voila! I now had an 80GB root filesystem without rebooting
>> a production machine!
>
> Yes, I see the point with being able to easily expand file systems on
> logical volumes. But IMHO the drawback of relying on this
> functionality is that it might tempt you to place almost your entire
> directory tree on a single file system.
Even without LVM, many people are tempted to do it that way, because
most GNU/Linux users today come from the world of Microsoft Windows, and
Windows installs everything in a single partition (and filesystem). So
does Apple OS X, by the way, even though technically ─ because of its
UNIX roots ─ it should be able to set things up differently there.
> The importance of having a small root file system might not be as
> important today with journaled file systems as it once used to be, but
> I still think that it feels safe to know that I will most likely be
> able to boot to single user mode and fsck all other file systems in
> case of power outage.
You can still have the root filesystem on an LVM volume, provided that
/boot is on a separate (and regular) partition ─ GRUB doesn't recognize
an LVM, although LILO might work.
That said however, having a small root filesystem has become very hard
these days due to all of the libraries and firmware blobs. This is why
RedHat and Fedora have begun implementing "the /usr move", where all of
those libraries and all binaries from the root filesystem are now moved
to under /usr ─ i.e. /bin, /lib{,64} and /sbin are now symbolic links to
their counterparts under the /usr hierarchy.
> Also, when different directory trees gets filled up to 100% different
> kind of bad stuff will happen. If /var/log gets filled up you will no
> longer get any logs... If /home gets filled up you will no longer be
> able to start any new X applications... If / gets filled up you will
> no longer be able to mount or umount any file systems.
>
> If all your directory trees lives in the same file system and that
> file system gets filled up all bad stuff will happen at once.
>
> My own / partition is 510 MB and that also includes the /boot
> directory.
My root partition is 466 MiB, of which 369 MiB is in use. I do have a
separate /boot partition of 309 MiB, of which only 51 MiB is in use at
the moment.
I've also got separate filesystems for /usr, /usr/local, /opt, /var,
/srv, /srv/mmedia/movies, /home, plus that the contents of /tmp live on
a tmpfs.
Each of these filesystems is mounted with custom mount options. For
instance, /boot, /usr, /usr/local and /opt are mounted read-only at boot
time. The root filesystem is mounted read/write at boot time, but gets
remounted read-only later on by rc.local because of two unrelated bugs
which both write junk to the root directory. /tmp is mounted with
noexec, and everything except for /dev is mounted with nodev. /home is
mounted with nosuid.
/root is a symlink to /home/root because there's a bug in the system so
that if you boot up in (or drop down to) runlevel 1, then it doesn't use
/root as the root user's home anyway ─ this is one of the two bugs which
periodically cause junk to be written to the root directory ─ and
instead it'll then use / as the superuser's home. So there was no point
in keeping /root on the root filesystem anymore, and this allows for the
root filesystem to be remounted read-only after all of the other boot
scripts have completed.
I don't have to drop down to runlevel 1 all that often, though. My
computer either way boots up to runlevel 3 and I start X manually after
login, so I can get away with doing most administrative stuff from
runlevel 3 without X running. ;)
Note: This is of course with a traditional sysvinit. I know you're
using Slackware, which has a BSD-style init, and distros with
systemd will of course also have different runlevel
implementations.
> My biggest partition is /var/images at 101G where I keep
> some iso- and hd- images I use with qemu.
My biggest partition is /home, with a 525 GiB capacity. However, only
5.6 GiB of that is currently in use. I've put all of my multimedia
stuff under /srv ─ that way, all user accounts have (read-only) access
to it and I've also cleaned out all the .iso files that I used to keep
under my $HOME.
--
= Aragorn =
http://www.linuxcounter.net - registrant #223157
[toc] | [prev] | [next] | [standalone]
| From | Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> |
|---|---|
| Date | 2016-06-08 22:23 +0200 |
| Message-ID | <nj9urp$ttc$1@saria.nerim.net> |
| In reply to | #3145 |
Aragorn a écrit : > > GRUB doesn't recognize an LVM GRUB 2 does, so you don't need a separate /boot.
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <rjk@greenend.org.uk> |
|---|---|
| Date | 2016-06-06 15:55 +0100 |
| Message-ID | <87eg8a4bat.fsf@LkoBDZeT.terraraq.uk> |
| In reply to | #3143 |
Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> writes: > Yes, I see the point with being able to easily expand file systems on > logical volumes. But IMHO the drawback of relying on this functionality > is that it might tempt you to place almost your entire directory tree on > a single file system. You can still have lots of separate filesystems with LVM, if that’s what you want. Indeed it’s easier with LVM than without, as you’re no longer committed to the sizes you chose for each of them. > The importance of having a small root file system might not be as > important today with journaled file systems as it once used to be, but > I still think that it feels safe to know that I will most likely be > able to boot to single user mode and fsck all other file systems in > case of power outage. I thought fsck of / was done from early userspace. -- http://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | Aragorn <thorongil@telenet.be.invalid> |
|---|---|
| Date | 2016-06-06 17:41 +0200 |
| Message-ID | <nj45ij$q4q$1@dont-email.me> |
| In reply to | #3146 |
On Monday 06 Jun 2016 16:55, Richard Kettlewell conveyed the following
to comp.os.linux.hardware...
> Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> writes:
>
>> The importance of having a small root file system might not be as
>> important today with journaled file systems as it once used to be,
>> but I still think that it feels safe to know that I will most likely
>> be able to boot to single user mode and fsck all other file systems
>> in case of power outage.
>
> I thought fsck of / was done from early userspace.
Yes, but what he means is that, once booted up in single-user
maintenance mode ─ i.e. runlevel 1 or equivalent on installations with a
different init system ─ he can then fsck all other filesystems manually
from there, as they will not be mounted yet.
Of course, LVM would not preclude this in any way, but Hendrik's
argument was in favor of not having everything on a single root
filesystem, and I agree with him on that.
Granted, in this day and age of virtual machine instances, "the cloud"
and so-called "rapid provisioning" ─ don't you love those buzzwords and
marketing terms? ─ the point would be moot. We now live in a time where
the robustness of any particular operating system installation has
become deprecated in favor of a dispose-and-replace strategy.
--
= Aragorn =
http://www.linuxcounter.net - registrant #223157
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <rjk@greenend.org.uk> |
|---|---|
| Date | 2016-06-06 17:23 +0100 |
| Message-ID | <878tyi477v.fsf@LkoBDZeT.terraraq.uk> |
| In reply to | #3147 |
Aragorn <thorongil@telenet.be.invalid> writes: > Richard Kettlewell conveyed the following to comp.os.linux.hardware... >> Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> writes: >>> The importance of having a small root file system might not be as >>> important today with journaled file systems as it once used to be, >>> but I still think that it feels safe to know that I will most likely >>> be able to boot to single user mode and fsck all other file systems >>> in case of power outage. >> >> I thought fsck of / was done from early userspace. > > Yes, but what he means is that, once booted up in single-user > maintenance mode ─ i.e. runlevel 1 or equivalent on installations with a > different init system ─ he can then fsck all other filesystems manually > from there, as they will not be mounted yet. One big filesystem: something’s wrong with /, so you run fsck in early userspace, fix it, boot normally, done. Many filesystems: something’s wrong with /home, so you run fsck in single user mode, fix it, boot normally, done. There doesn’t seem to be any practical difference between the two scenarios. (Henrik may have other requirements justifying multiple filesystems, the point is just that ability to fsck things doesn’t seem to be one of them, since he can do so either way.) -- http://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@invalid.es> |
|---|---|
| Date | 2016-06-06 22:36 +0200 |
| Message-ID | <le3h2d-pjs.ln1@Telcontar.valinor> |
| In reply to | #3149 |
On 2016-06-06 18:23, Richard Kettlewell wrote: > One big filesystem: something’s wrong with /, so you run fsck in early > userspace, fix it, boot normally, done. > > Many filesystems: something’s wrong with /home, so you run fsck in > single user mode, fix it, boot normally, done. > > There doesn’t seem to be any practical difference between the two > scenarios. With one filesystem only the problem is that if something goes very wrong, you risk the entire lot. The advantage is space optimization. With two filesystem, one for home, another for system, which is a middle ground, the advantage is that you can replace the system release or distribution without touching the data (unless you run daemons/servers). There are many choices :-) Oh, by the way: Windows has its own LVM type of setup. I forget the name. Dynamic volumes, perhaps. People like me also installed Windows separating system and user "disks". The "My documents" directory could be another partition. It was the people that sold the computers already installed which skipped this step. -- Cheers, Carlos. --- news://freenews.netfront.net/ - complaints: news@netfront.net ---
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <rjk@greenend.org.uk> |
|---|---|
| Date | 2016-06-06 21:51 +0100 |
| Message-ID | <8737oq3usg.fsf@LkoBDZeT.terraraq.uk> |
| In reply to | #3150 |
"Carlos E.R." <robin_listas@invalid.es> writes: > On 2016-06-06 18:23, Richard Kettlewell wrote: >> One big filesystem: something’s wrong with /, so you run fsck in early >> userspace, fix it, boot normally, done. >> >> Many filesystems: something’s wrong with /home, so you run fsck in >> single user mode, fix it, boot normally, done. >> >> There doesn’t seem to be any practical difference between the two >> scenarios. > > With one filesystem only the problem is that if something goes very > wrong, you risk the entire lot. The advantage is space optimization. As I said: | (Henrik may have other requirements justifying multiple filesystems, | the point is just that ability to fsck things doesn’t seem to be one | of them, since he can do so either way.) Taking guesses at those reasons doesn’t make the non-reason any more convincing. -- http://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> |
|---|---|
| Date | 2016-06-07 04:54 +0000 |
| Message-ID | <nj5k2h$g7o$1@dont-email.me> |
| In reply to | #3149 |
On Mon, 06 Jun 2016 17:23:16 +0100, Richard Kettlewell wrote: > One big filesystem: something’s wrong with /, so you run fsck in early > userspace, fix it, boot normally, done. But what if the / filesystem is so broken that it cannot even be mounted readonly? If so, you will not be able to reach those early userspace startup scripts or /sbin/fsck. Then your only option will be to boot from some kind of live CD to fsck your / filesystem. At least that used to be the case, today many systems boot with some initrd before / is mounted. > Many filesystems: something’s wrong with /home, so you run fsck in > single user mode, fix it, boot normally, done. > > There doesn’t seem to be any practical difference between the two > scenarios. > (Henrik may have other requirements justifying multiple filesystems, My other point is to avoid that all directory trees gets full at the same time in case something starts filling up your disk. This something might be logs spitting out from non normal behavior or a user running some program which fills up /home or some tmp-directory. regards Henrik -- The address in the header is only to prevent spam. My real address is: hc351(at)poolhem.se Examples of addresses which go to spammers: root@localhost postmaster@localhost
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <rjk@greenend.org.uk> |
|---|---|
| Date | 2016-06-07 08:43 +0100 |
| Message-ID | <87twh530mz.fsf@LkoBDZeT.terraraq.uk> |
| In reply to | #3152 |
Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> writes: > Richard Kettlewell wrote: >> One big filesystem: something’s wrong with /, so you run fsck in early >> userspace, fix it, boot normally, done. > > But what if the / filesystem is so broken that it cannot even be mounted > readonly? If so, you will not be able to reach those early userspace > startup scripts or /sbin/fsck. Early userspace happens before mounting the root filesystem (indeed it’s the thing that tries to mount it). -- http://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> |
|---|---|
| Date | 2016-06-07 19:04 +0000 |
| Message-ID | <nj75so$s4o$2@dont-email.me> |
| In reply to | #3153 |
On Tue, 07 Jun 2016 08:43:00 +0100, Richard Kettlewell wrote: > Early userspace happens before mounting the root filesystem (indeed it’s > the thing that tries to mount it). If so, I guess that you describe one of those systems which use an initrd mechanism during boot. Not all systems are configured that way, some systems still get the root file system mounted by the kernel. regards Henrik -- The address in the header is only to prevent spam. My real address is: hc351(at)poolhem.se Examples of addresses which go to spammers: root@localhost postmaster@localhost
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <rjk@greenend.org.uk> |
|---|---|
| Date | 2016-06-07 20:30 +0100 |
| Message-ID | <87oa7c3ig4.fsf@LkoBDZeT.terraraq.uk> |
| In reply to | #3154 |
Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> writes: > On Tue, 07 Jun 2016 08:43:00 +0100, Richard Kettlewell wrote: >> Early userspace happens before mounting the root filesystem (indeed it’s >> the thing that tries to mount it). > > If so, I guess that you describe one of those systems which use an > initrd mechanism during boot. Not all systems are configured that > way, some systems still get the root file system mounted by the > kernel. Yes, that’s what early userspace means. -- http://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | comp.os.linux.hardware
csiph-web