[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[linux-lvm] LVM deployment tips ?



hi lvm'rs,

Ive begun to think about really using lvm, ie to handle /home, /usr,
as well as /tmp, other mundane stuff.

This requires planning I said, then decided it was strategy;
how to use the namespaces of VGs, LVs, PVs across 3 ides?

heres some assertions, ( and wild speculations, despite my authoritative tone )
please disabuse me of any errs, wrong thinking.
who knows, maybe its a perfect what-not-to-do.


PVs reside on partitions; ex /dev/hdb2
PVs can split a hard drive by speed.

Partition speed is widely understood to vary linearly with head radius
from spindle, more area at edge can hold more data, and which is then
read/written faster.  Addition of PVs can make LV less reliable; it now
depends on continued operation of multiple disks.

an LV can have multiple PVs, and can extend and reduce the LVs
by allocating more space from the currently used PVs, or by adding
entirely new PVs.

an LV can have its PVs striped together for BW needs.
striped LVs should never use 2 PVs from same drive.
the PV-stripes used should have similar perf #s

LVs are also used to contain snapshots.  these work like
jfs in that they preserve a consistent view of a set of files,
even as other users change the 'current' copies.

snapshots are not talked about in terms of commit / rollback.
this seems unfortunate, even if to say that snapshots cant rollback.
Someday we might get such a feature - 'restore-fs-on-reboot',
but w/o the reboot.

VGs are mostly used to container-ize data ownership,
and for administrative control, backup.  Multiple VGs
are mostly used in larger installations.

Std pcs have only 4 ide drives, limiting multi-platter parallelism.
how best to use VGs here ? removable drives ?

Tuning LVs by recomposing them of different PVs
is a time-consuming process; measuring LV traffic with
lvmsadc, lvmsar requires that you have representative loads.

For example, if you balance loads to /usr, /home/httpd/docroot,
/var/log, you may fail cuz you ignored database io loads.
This is why man lvmsar says to use a cron-job, you get to
see real data, and hopefully load patterns.

putting each dir above into a striped LVs may not be beneficial,
particularly when they compete with each other for the spindle.
Such a config would serialize access to those LVs, rather than
each dir having its own spindle.

swag: lvmsar can report io loads against each PV and LV,
but not on PEs.  (PE activity wouldnt tell you much w/o
knowing the files residing there - and this would undermine
the abstraction)


are these true ? do they have any value as guidance ?

Journalling file-systems (JFS) ?

JFS seems to have a natural advantage on growable partitions.  What are the major
features of, and distinctions between; reiserfs, ext3, xfs, jffs, xyz, etc  ??

features such as transparency and auto-sync with lvextend/reduce
seem a be high priority.  Interaction-cooperation between snapshots
and jfs would be interesting.

JFS should in the end be better at journalling, can LVM be considered
jfs-lite, or perhaps jfs-block ?  This leaves out issues

even bigger swag:

fs-load-monitoring tools are / can be much better
in real JFS, as the fs can know in detail where the load is going.
However, how to create info from such data is unclear.

In contrast, LVM-sar only separates on boundaries (LVs) you create explicitly,
it doesnt do tuning & analysis for free.

It could be possible to use snapshots or similar to create monitors on directories
somewhere within a partition.  Ex; it could separately count loads to /usr, /usr/local,
even if /usr/local werent actually a different partition, by suitable setup.

lastly,

what would happen if I lvextend'd an ext2 partition ?
would an fsck fail immediately / later, or would it never see
the new space ?    Is it thus possble to create 'hidden' storage,
(similar to files in /tmp hidden when /tmp becomes mount point for /dev/hdc3 )

tia
jimc







[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]