primary partitions - Hardware

This is a discussion on primary partitions - Hardware ; On Mon, 02 Jun 2008 05:41:08 +0200 Aragorn wrote: | With LVM, you can create multiple pseudo-partitions inside an existing real | partition (which doesn't hold a filesystem yet). I suggest that instead of | using up real partitions from ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 22 of 22

Thread: primary partitions

  1. Re: primary partitions

    On Mon, 02 Jun 2008 05:41:08 +0200 Aragorn wrote:

    | With LVM, you can create multiple pseudo-partitions inside an existing real
    | partition (which doesn't hold a filesystem yet). I suggest that instead of
    | using up real partitions from the start, you would do the following -
    | presuming that the laptop's hard disk is on an SATA bus:
    |
    | - */dev/sda1* = Vista C: drive (primary partition, bootable)
    | - */dev/sda2* = extended partition container
    | - */dev/sda5* = Vista D: drive (logical partition, see *[1]*)
    | - */dev/sda6* = stable GNU/Linux installation */boot
    | - */dev/sda7* = stable GNU/Linux installation root filesystem
    | - */dev/sda8* = Linux swap partition (see *[2]*)
    | - */dev/sda9* = testing GNU/Linux root filesystem, see *[3]*)
    | - */dev/sda10* = stable GNU/Linux */home* (see *[4]*)
    | - */dev/sda11* = testing GNU/Linux */home*
    | - */dev/sda12 = LVM (see *[5]*)

    Nice layout. Of course my needs are different so I have another design.


    | *[1]* I recommend formatting this with /vfat/ - FAT32 in Microsoft-speak -
    | so that you have a filesystem that can be read and written to by both Vista
    | and GNU/Linux, in the event that you want to share certain files between
    | both platforms. However, do _*not*_ use this as your */home*
    | because /vfat/ does not support UNIX file ownerships and permissions.

    A good idea!

    I always have a separate D: drive in Windows for all data files, and
    even put the desktop directory there. This is so that Windows can be
    re-installed without losing data (actually I refresh the C: drive
    with a compressed image copy using Linux as the tool). What I don't
    know is which would be the better choice to combine these purposes:

    1. D: for data, E: in FAT32 for file sharing
    2. D: in FAT32 for both data and file sharing

    Number 1 might gain better performance in Windows, especially Vista.
    Number 2 is more flexible in case you might need _any_ file from your
    data while Linux is up.

    FYI, I'm just about to upgrade from Win98 to XP ;-)
    OTOH, I typically use Windows about every 2-3 years. I haven't brought
    up Windows since around 2006. I'll be trying to install Windows under
    some kind of virtualization this time.


    | *[3]* Since your intention is to only test other distributions, there is no
    | need to diversify the filesystem hierarchy within such a test install, and
    | so you can keep everything on the test distribution's root filesystem,
    | except for */home* - see below.
    |
    | *[4]* Keeping your */home* filesystems separate allows you to reformat the
    | */home* of a test distro while keeping your normal distro - which I've
    | labeled "stable" in the above partitioning layout - secured. However,
    | having it separated from the test distro's root filesystem allows you to
    | install and reinstall that test distro (or another one) without having to
    | reformat that */home* and lose your data. It's also easier if you want to
    | copy or move data between the two installed distributions without needing
    | to mount the other distribution's root filesystem.

    I use a kernel patch I wrote that lets me use a rootdir= boot parameter to
    select the subdirectory to become / within the filesystem selected by the
    usual root= boot parameter.

    http://phil.ipal.org/linux/kernel/patch/rootdir/


    | *[5]* Aside from keeping */boot* and */home* separate, I would also
    | recommend having */usr,* */opt,* */var* and */tmp* separated. The former
    | two are static filesystems, which should for good measure even be mounted
    | read-only during normal system operation.

    I put /usr and /opt on the same filesystem. On my machines, it is sda9.
    Instead of using a symlink (long ago I did /opt -> ../usr/opt), I now do
    this with a bind mount. The sda9 filesystem has top level directories
    named opt and usr. I first mount /dev/sda9 as /mnt/sda9. Then I bind
    mount /mnt/sda9/opt as /opt and /mnt/sda9/usr as /usr. So there is none
    of that occaisional software confusion a symlink can cause. It is mounted
    read-only, too.


    | */var* is a filesystem that's being written to a lot by your system's
    | daemons - e.g. /syslogd,/ among others; it also contains print spools, for
    | instance - and that you best keep separated from the root filesystem. In
    | fact, the root filesystem itself should be kept quite small if you decide
    | to split off sections of the filesystem hierarchy. Ideally, it should be
    | no larger than 250-300 MB.

    I mount /var with the "noatime" option (also /home). This can interfere
    with correct recognition of new mail, so if the machine also has locally
    delivered mail, I make the mail spool yet another partition and don't use
    "noatime" for it.


    | */tmp* is similar to */var,* albeit that its contents are quite different.
    | It mainly consists of sockets, and nothing in */tmp* should be expected to
    | survive a reboot. It is therefore best - also for security reasons - to
    | have */tmp* as small as possible, and I personally prefer having it exist
    | on a /tmpfs/ rather than on the physical disk. /tmpfs/ is a swappable
    | RAM-based filesystem that has its own mount options. See...

    Many programs expect to use temporary files there (such as "sort") and my
    usage of these is sometimes rather large. I've found I need about 2GB
    these days for /tmp. YMMV


    | Given your intended usage of the machine, I would thus install the above
    | filesystems in logical volumes. You only need one partition for that,
    | which you prepare for LVM usage with /pvcreate/ - see the /man/ page for
    | details. This would be the equivalent step to creating a filesystem on it
    | after having created the partition itself, but we're not quite there yet,
    | because LVM is an abstraction layer above physical partitioning.

    Occaisionally, when I am doing distribution tests, I do virtualization.
    I haven't yet needed to go to LVM for that (but some distributions use
    LVM by default ... e.g. red fedora hat).


    | You can then use these device special files - or eventually a filesystem
    | label, or a UUID if you like - in */etc/fstab,* just as you would for
    | regular partitions.

    I've found the filesystem label lookups seem to work. So I'm looking at
    moving in that direction.

    Here is my current layout (as seen by df -a on one of my machines).
    Note that / is tmpfs. It's running a modified Slackware.

    Filesystem 1K-blocks Used Available Use% Mounted on
    tmpfs[root] 8192 1036 7156 13% /
    proc 0 0 0 - /proc
    sysfs 0 0 0 - /sys
    tmpfs[dev] 1024 44 980 5% /dev
    tmpfs[etc] 16384 8612 7772 53% /etc
    tmpfs[shm] 163840 0 163840 0% /dev/shm
    devpts 0 0 0 - /dev/pts
    /dev/sda1 252272 192248 60024 77% /admin
    /dev/sda9:bin 7661300 6133172 1528128 81% /bin
    /dev/sda1:boot 252272 192248 60024 77% /boot
    /dev/sda4:home 717644332 676843108 40801224 95% /home
    /dev/sda9:lib 7661300 6133172 1528128 81% /lib
    /dev/sda9pt 7661300 6133172 1528128 81% /opt
    /dev/sda8pt/local 512968 61288 451680 12% /opt/local
    /dev/sda4ub 717644332 676843108 40801224 95% /pub
    /dev/sda5:root 1028060 90276 937784 9% /root
    /dev/sda9:sbin 7661300 6133172 1528128 81% /sbin
    /dev/sda6:tmp 2056188 585576 1470612 29% /tmp
    /dev/sda9:usr 7661300 6133172 1528128 81% /usr
    /dev/sda8:usr/local 512968 61288 451680 12% /usr/local
    /dev/sda5:var 1028060 90276 937784 9% /var
    /dev/sda7:var/log 1028060 82348 945712 9% /var/log
    /dev/sda6:var/tmp 2056188 585576 1470612 29% /var/tmp
    /dev/sda4:web 717644332 676843108 40801224 95% /web
    tmpfs[empty] 4 0 4 0% /var/empty
    tmpfs[lock] 4155668 0 4155668 0% /var/lock
    tmpfs[run] 4155668 100 4155568 1% /var/run
    /dev/sdb4 717644332 682036060 35608272 96% /mnt/sdb4
    /dev/sdc4 963881104 580904208 382976896 61% /mnt/sdc4
    /dev/sdd1 488371584 462271808 26099776 95% /mnt/sdd1
    /dev/sde1 488371584 462271772 26099812 95% /mnt/sde1
    /dev/sdj1 488371584 462118076 26253508 95% /mnt/sdj1
    /dev/sdk1 488371584 462271944 26099640 95% /mnt/sdk1

    (sda/sdb are SATA, sdc is Firewire, and sdd/sde/sdj/sdk are USB)

    --
    |WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
    | by the abuse department, bellsouth.net is blocked. If you post to |
    | Usenet from these places, find another Usenet provider ASAP. |
    | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

  2. Re: primary partitions

    On Sunday 15 June 2008 02:03, someone who identifies as
    *phil-news-nospam@ipal.net* wrote in /comp.os.linux.hardware:/

    > On Mon, 02 Jun 2008 05:41:08 +0200 Aragorn
    > wrote:
    >
    > | With LVM, you can create multiple pseudo-partitions inside an existing
    > | real partition (which doesn't hold a filesystem yet). I suggest that
    > | instead of using up real partitions from the start, you would do the
    > | following - presuming that the laptop's hard disk is on an SATA bus:
    > |
    > | - */dev/sda1* = Vista C: drive (primary partition,
    > | bootable)
    > | - */dev/sda2* = extended partition container
    > | - */dev/sda5* = Vista D: drive (logical partition, see
    > | *[1]*)
    > | - */dev/sda6* = stable GNU/Linux installation */boot
    > | - */dev/sda7* = stable GNU/Linux installation root
    > | filesystem
    > | - */dev/sda8* = Linux swap partition (see *[2]*)
    > | - */dev/sda9* = testing GNU/Linux root filesystem, see
    > | *[3]*)
    > | - */dev/sda10* = stable GNU/Linux */home* (see *[4]*)
    > | - */dev/sda11* = testing GNU/Linux */home*
    > | - */dev/sda12 = LVM (see *[5]*)
    >
    > Nice layout. Of course my needs are different so I have another design.


    Mind you that the above layout was devised in my mind only at the time of
    writing my reply. :-) I don't use Windows myself, so I also don't wish to
    have that junk on my hard disk(s).

    > | *[1]* I recommend formatting this with /vfat/ - FAT32 in Microsoft-speak
    > | - so that you have a filesystem that can be read and written to by both
    > | Vista and GNU/Linux, in the event that you want to share certain files
    > | between both platforms. However, do _*not*_ use this as your */home*
    > | because /vfat/ does not support UNIX file ownerships and permissions.
    >
    > A good idea!
    >
    > I always have a separate D: drive in Windows for all data files, and
    > even put the desktop directory there. This is so that Windows can be
    > re-installed without losing data (actually I refresh the C: drive
    > with a compressed image copy using Linux as the tool). What I don't
    > know is which would be the better choice to combine these purposes:
    >
    > 1. D: for data, E: in FAT32 for file sharing
    > 2. D: in FAT32 for both data and file sharing
    >
    > Number 1 might gain better performance in Windows, especially Vista.
    > Number 2 is more flexible in case you might need _any_ file from your
    > data while Linux is up.


    From the security point of view, option number 1 would be better, of course.
    FAT32 does not support the ACLs that Windows uses for security either. On
    the other hand, option 2 is more flexible, as you say.

    > | */var* is a filesystem that's being written to a lot by your system's
    > | daemons - e.g. /syslogd,/ among others; it also contains print spools,
    > | for instance - and that you best keep separated from the root
    > | filesystem.
    > | In fact, the root filesystem itself should be kept quite small if you
    > | decide to split off sections of the filesystem hierarchy. Ideally, it
    > | should be no larger than 250-300 MB.
    >
    > I mount /var with the "noatime" option (also /home). This can interfere
    > with correct recognition of new mail, so if the machine also has locally
    > delivered mail, I make the mail spool yet another partition and don't use
    > "noatime" for it.


    There also is the /relatime/ mount option, as a compromise between /atime/
    and /noatime./ /relatime/ only updates the atime if /mtime/ is newer
    than /ctime,/ or so I gather - I use /noatime/ for everything on my
    systems. ;-)


    --
    *Aragorn*
    (registered GNU/Linux user #223157)

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2