Prev: Hauppauge HVR 2250 in Suse 11.1?
Next: scanners for use with Linux under the sane system
From: Aragorn on 13 Oct 2009 22:02
On Tuesday 13 October 2009 20:28 in comp.os.linux.hardware, somebody
identifying as =SERGE= wrote...

> Hello,
>
> How should I use a 1 TB hd? The disk is intended to store music files
> and videos.
> Can just make 1 huge 1TB partition or maybe it's better to split the
> disk in two partions?
> Or there is no difference at all?

Well, the question you are asking is one that involves a lot of personal
taste, actually, so in essence only you would be qualified to judge how
you will be using this disk. ;-) Personally however, I would suggest
the following...

Given the intended use of the disk for music files and video - so
basically, it's all multimedia stuff - I would first of all mount
whatever partitions you'll create on it to */srv* or a subdirectory
thereof. The */srv* directory is not implemented in most GNU/Linux
distributions, but it is specified in the File Hierarchy Standard (FHS)
version 2.3, and it is intended for shareable data.

So how to go about this? Well, one could use a single partition, or one
could distinguish between that which is solely audio and that which is
video (with audio, of course), in which case there would be two
partitions. However, the question then arises on what capacity to use
for either partition, and whether one partition will not prove to be
too large and the other too small at some point in the future.

Therefore, I would propose making use of LVM. You use /pvcreate/ to
prepare the disk for logical volumes - it is not necessary to create a
classic partition on it, although you can, and if so, then you should
only create one partition.

So say that this disk is of the SATA type and that it is your second
disk, then the disk itself would be */dev/sdb* and the partition you
create on it would be */dev/sdb1.* If you create a partition, then
that partition is what you should use /pvcreate/ on. Next, you
use /vgcreate/ to create a volume group - let's call it
*/dev/multimedia* or something - and in it, you create two logical
volumes - e.g. */dev/multimedia/audio* and */dev/multimedia/video* -
using /lvcreate./ (Note: all of the LVM tools have excellent /man/
pages, so be advised to read them before using the tools.)

Most modern distributions automatically scan all available hard disks
for logical volume groups and logical volumes at boot time, but
you /may/ have to look at your /init/ scripts to ensure that the new
disk will be scanned as well. This scanning is necessary because
logical volumes are an abstraction layer above the physical layer of
disks and partitions, and thus the kernel needs to be told of the
existence of those volumes before you can mount and access them. The
fact that LVM is an abstraction layer also translates in the need for
the */boot* filesystem - or the root filesystem if you don't have a
separate */boot* partition - to reside on a physical partition if
you're going to use GRUB as a bootloader, because GRUB knows about
partitions and filesystems but GRUB isn't capable of loading a kernel
off a logical volume.

Now, why would you use logical volumes? Well, as I mentioned higher up,
partition sizes are static, and you may want to adjust the size on the
fly depending on your needs. Logical volume management is far more
flexible than fixed-size partitions, eventhough you can of course grow
traditional partitions and filesystems if enough free diskspace is
available, and eventhough even logical volumes have their limitations.

Yet there is a lot more you can do with LVM than with fixed partitions,
and in addition to that, you are not limited to the maximum amount of
regular partitions per disk that the kernel allows - i.e. 15 partitions
per disk with SAS/SCSI/SATA/USB and the newer /libata/ approach to
IDE/PATA disks (i.e. the */dev/sd[az]* device nodes) or 63 partitions
per disk with the older legacy IDE/PATA driver code (i.e. the
*/dev/hd[az]* device nodes).

Considering the dynamic nature of the data you will be storing on that
disk, I definitely recommend using LVM. Create two volumes of about
equal size, or differing size if more appropriate to your present
situation. Make them large enough to hold the data you currently have,
but leave enough extra space available on the disk - or on the
partition, should you choose to create one - to grow either logical
volume when expansion is needed. The extra free space can always be
alotted to either of the two volumes without having to reformat
anything or fiddle with partition tables, simply by using the LVM
tools.

Hope this was helpful. ;-)

--
*Aragorn*
(registered GNU/Linux user #223157)
From: Aragorn on 13 Oct 2009 22:07
On Tuesday 13 October 2009 21:32 in comp.os.linux.hardware, somebody
identifying as Jon Solberg wrote...

> On 2009-10-13, ray <ray(a)zianet.com> wrote:
>> On Tue, 13 Oct 2009 22:28:40 +0400, =SERGE= wrote:
>>
>
>>> How should I use a 1 TB hd? The disk is intended to store music
>>> files and videos.
>>> Can just make 1 huge 1TB partition or maybe it's better to split the
>>> disk in two partions?
>>> Or there is no difference at all?
>>
>> Main difference I can think of is: how to plan to back things up - or
>> do you? It's going to be a pain to backup 1tb.
>
> No, you just get two additional drives and keep them in separate
> psychical locations. :-)

I would recommend *physical* locations instead. Psychic locations might
prove interesting but may be a little harder to implement. :pp

(Just kidding, of course - I know that it was a typo and that English is
not your main language. ;-))

--
*Aragorn*
(registered GNU/Linux user #223157)
From: Jon Solberg on 14 Oct 2009 02:57
On 2009-10-14, Aragorn <aragorn(a)chatfactory.invalid> wrote:
> On Tuesday 13 October 2009 21:32 in comp.os.linux.hardware, somebody
> identifying as Jon Solberg wrote...
>
>> On 2009-10-13, ray <ray(a)zianet.com> wrote:
>>> On Tue, 13 Oct 2009 22:28:40 +0400, =SERGE= wrote:
>>>
>>
>>>> How should I use a 1 TB hd? The disk is intended to store music
>>>> files and videos.
>>>> Can just make 1 huge 1TB partition or maybe it's better to split the
>>>> disk in two partions?
>>>> Or there is no difference at all?
>>>
>>> Main difference I can think of is: how to plan to back things up - or
>>> do you? It's going to be a pain to backup 1tb.
>>
>> No, you just get two additional drives and keep them in separate
>> psychical locations. :-)
>
> I would recommend *physical* locations instead. Psychic locations might
> prove interesting but may be a little harder to implement. :pp
>
> (Just kidding, of course - I know that it was a typo and that English is
> not your main language. ;-))

Oops. I blame it all to ispell. ;-)

--
Jon Solberg (remove "nospam." from email address).
From: David Brown on 14 Oct 2009 03:00
Chris Cox wrote:
> On Tue, 2009-10-13 at 18:40 +0000, ray wrote:
>> On Tue, 13 Oct 2009 22:28:40 +0400, =SERGE= wrote:
>>
>>> Hello,
>>>
>>> How should I use a 1 TB hd? The disk is intended to store music files and
>>> videos.
>>> Can just make 1 huge 1TB partition or maybe it's better to split the disk in
>>> two partions?
>>> Or there is no difference at all?
>>>
>>> Thank you
>> Main difference I can think of is: how to plan to back things up - or do
>> you? It's going to be a pain to backup 1tb.
>
> Other filesystem operations like "fsck" will take much longer when the
> filesystem is huge.
>

That varies somewhat with the filesystem. ext4 will not take long to
fsck until there are a lot of files on the disk (and even then it will
be faster than ext3). For some filesystems, such as XFS (IIRC), the
fsck uses more memory for larger partitions - it is possible to build a
filesystem that your machine can't fsck at all due to memory
constraints. So check the details before committing to a filesystem
(especially as XFS has a reputation for being good for servers with
large files).

> With that said, I'd put the whole thing under LVM control and carve out
> volumes from there and grow them as needed dynamically (in other words,
> don't use the whole space initially, you might find you need a filesytem
> for this or that...)
>

I'd agree fully with that - LVM makes life much easier even if you only
have a single working partition to start with.

It can also side-step the fsck issue - you take a snapshot of the real
filesystem partition, and run an fsck on the snapshot. If the snapshot
fsck shows errors, you umount and repair the main partition - otherwise,
use tune2fs to set the "mount-count" to 0 so that the main partition
will not be checked automatically for a while yet. And since this
checking runs in the background while the main partition is in full use,
it doesn't matter if it takes a while.
From: Andrew Gideon on 14 Oct 2009 09:21
On Wed, 14 Oct 2009 09:00:13 +0200, David Brown wrote:

> It can also side-step the fsck issue - you take a snapshot of the real
> filesystem partition, and run an fsck on the snapshot. If the snapshot
> fsck shows errors, you umount and repair the main partition - otherwise,
> use tune2fs to set the "mount-count" to 0 so that the main partition
> will not be checked automatically for a while yet.

Is this reliable? I'd think that it would tend to cause "false
positives" (that is, you'll see fsck failures on the snapshot that aren't
really a problem).

The reason I'd envision this is that an LVM snapshot operation is block
level. If you take a snapshot when the file system is active, the file
system may not be in a stable/quiescent state, resulting in complaints
from fsck.

I expect that, if you unmounted the volume before the snapshot, you'd
resolve this problem. Is that a necessary step? Is there some other way
to force a filesystem into a quiescent state during a block-level
snapshot by LVM? Or is there something about this that I'm missing?

- Andrew
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Hauppauge HVR 2250 in Suse 11.1?
Next: scanners for use with Linux under the sane system