From: spamtrap42@jacob21819.net
On 2013-01-23, Aragorn wrote:
> On Wednesday 23 January 2013 05:25, Robert Riches conveyed the following
> to alt.os.linux.mandriva...
>
>> On 2013-01-23, Aragorn wrote:
>>> On Wednesday 23 January 2013 00:18, faeychild conveyed the following
>>> to alt.os.linux.mandriva...
>>>
>>>> I think this time I will create a separate partition for "HOME"
>>>>
>>>> I am never quite sure how much to allow for "ROOT"
>>>
>>> This is what I currently have with Mageia 1, with a very fair amount
>>> of
>>> software installed, including many development packages. You can use
>>> this as an example to calculate your needed disk space from.
>>>
>>> (Note: Duplicate and/or irrelevant entries [*] have been removed from
>>> the list for clarity.)
>>>
>>> Filesystem Size Used Avail Use% Mounted on
>>> rootfs 445M 352M 94M 80% /
>>> none 2.0G 4.0K 2.0G 1% /tmp
>>> /dev/sda1 295M 48M 247M 17% /boot
>>> /dev/sda3 25G 6.1G 19G 25% /usr
>>> /dev/sda5 744M 212K 744M 1% /usr/local
>>> /dev/sda6 1.5G 160K 1.5G 1% /opt
>>> /dev/sda7 5.9G 368M 5.5G 7% /var
>>> /dev/sda8 489G 16G 473G 4% /home
>>> /dev/sda9 40G 18G 22G 44% /srv
>>>
>>> Notes:
>>>
>>> 1. /tmp is a tmpfs on my system.
>>>
>>> 2. I ended up wasting a lot of space on /opt and /usr/local -
>>> strictly speaking, you only need a separate /usr/local if you
>>> build a lot of code from sources, which I have not yet done her
>>> - as well as on /usr itself, but that's because I had
>>> anticipated installing a number of games, which I ended up not
>>> doing after all due to the lack of 3D support in my video
>>> driver.
>>>
>>> 3. I've used traditional partitions here, but by putting everything
>>> except for /boot and the root filesystem on LVM2, you can better
>>> handle the size requirements. It's rather easy to enlarge a
>>> logical volume afterwards if need be, and logical volumes can
>>> span across multiple disks.
>>>
>>>
>>> [*] Given that I have /etc/mtab symlinked to /proc/self/mounts, there
>>> is a duplicate entry for the root filesystem (as /dev/root), and
>>> then /dev and /dev/shm were also listed.
>>
>> Having a separate partition/filesystem for /home is a good idea.
>> If you have an existing installation that has at least a somewhat
>> similar set of packages as the new system, another idea for
>> sizing the root filesystem is to allocate double the space the
>> old release is actually using. That should leave a reasonable
>> amount of headroom for growth.
>
> Well, not necessarily based upon a previous install, my general aim at
> installation time is to have approximately 40% of the space left as
> headroom for future growth, except on /boot and the root filesystem
> itself - but as you could see, I've split off just about everything from
> the root filesystem - because the actual root filesystem doesn't need to
> be big at all.
The actual root filesystem doesn't need to be big, but /usr does
take a considerable amount of space. /var and /opt can also take
considerable space depending on what's on the system.
>> If going from 32-bits to 64-bits, allocating triple (or quadruple
>> space if you can afford space) may be safer, because 64-bits will take
>> at least a little more space than 32-bits.
>
> There is a general misconception that 64-bit binaries would be
> significantly larger - even double the size - than 32-bit binaries, but
> the truth of the matter is that a 64-bit distribution typically consumes
> more diskspace than its 32-bit sibling due to the fact that most 64-bit
> distributions are multilib, and that they thus also contain a
> significant amount of 32-bit libraries and possibly even 32-bit
> executables. ;-)
I wouldn't go so far as to claim 64-bit binaries would be double
the size, and a lot of the increased size is due to the presence
in many situations of both 64-bit and 32-bit libraries and
perhaps executables. However, a modern 64-bit instruction set
will almost certainly have lower code density than 32-bit
CISC-based x86, simply because the 8086 and successors were
optimized (as were the VAX and other 1980-ish CISCs) for code
density with prefix bytes and byte-aligned instructions. A
modern 64-bit instruction set will be designed mostly for speed,
with code density being a very minor factor. Also, there are
some constants embedded in executables and libraries that will be
larger.
For a real-world example, a the Mageia 2 xload RPM contains only
three files:
/usr/bin/xload
/usr/share/X11/app-defaults/XLoad
/usr/share/man/man1/xload.1.lzma
The latter two files are almost certainly the same size in 32-bit
and 64-bit versions. The (rather highly compressed) executable
would thus be the major contributor to any difference in size.
Here are the sizes of the .rpm files:
12660 xload-1.1.0-1.mga1.i586.rpm
12773 xload-1.1.0-1.mga1.x86_64.rpm
A comparison of the sizes of the uncompressed executable
(obtainable via rpm2cpio) would undoubtedly show a bigger
difference.
--
Robert Riches
spamtrap42@jacob21819.net
(Yes, that is one of my email addresses.)
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
