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

Re: About /etc/fstab and LABELs



Ed Wilts wrote:

On Fri, Oct 07, 2005 at 12:57:03AM +0300, Kostas Sfakiotakis wrote:
Ed Wilts wrote:

Labels can save you from MAJOR problems in a lot of specific situations.
Imagine that you have 3 disks, sda, sdb, and sdc.  Now imagine that sdb
fails hard.
Well the problem is that sdb failled and the DATA whatever
they were are gone !!! and certainly there is no label trick
that is going to save someone from that .

No, but you should not lose other data because of it.

I don't know if you agree with me on that but backups do serve
on that purpose . A nice backup will help on the direction of not
loosing data or in the worst occassion minimize the loss .

Predictability in system configurations is what keeps us employed.
You reboot and what was sdc is now sdb.  You will mount
that filesystem on the wrong mount point and suddenly cause yourself all
sorts of grief and possible disk corruption depending on how well
behaved your applications are.  Imagine that sdb was your backup drive
and you did an rsync --delete from sda to sdb automatically via cron or
in rc.local.  Kiss all the data that was on sdc goodbye

Well i thought there was a Rescue mode in Linux . Since there is
a disaster rescue mode can be used to edit the scripts so they
reflect the current situation .

You're assuming you caught the issue in time.  What if your swap file
was on sdb?  Your system will likely crash, it will hopefully come up
but sdc becomes sdb.  You may come up without swap.

You caught me there , i don't know what happens if a system
tries to boot without a swap partition.  In case there is enough
memory available it might boot in case there is not enough memory
though ...... it is pretty possible that it will crash . Now as far as the
damage is concerned i guess it depends on what filesystems were
mounted at that point and what was going on at the point of the crash ...

The whole point is to make sure that the system actions are predictable
- what is sdc today will always be sdc - the mount point follows the
physical disk.
In that perspective i can't say that things work otherwise .
In another point of view i would try though to the best of
my ability not to loose DATA no matter what happens .

The same problem came occur if you add a drive - there's no guarantee
that your system will scan the drives in the same order when you come
up after the drive install.

Since you are focusing on the sd* notation i guess you are
focusing to what happens on a SCSI controller , on the other
hand IDE controllers are tottaly independent from that problem

For example /dev/hdc will always refer to the Secondary Master
no matter if it is the only device or if there are 3 or more devices
connected to the computer ( I used to run Redhat 7.3 on a computer
with a PDC 20267 controller with a total of 4 disks a cdrecorder and
a cd drive and i never had a problem .

Besides  answer me this : Let's assume that on one box you have
Redhat 7.3 but because it is out of date you want to install on the
same box  Fedora Core 4 for example ( Dual boot with 2 Linux
versions ) . If you use labels for the root device , then on boot
how will the Redhat 7.3 know which is it's root partition so it will
try to boot from there and which is the Fedora Core 4 ( btw a
2.6.* kernel and NOT a 2.4 ) so it will not use it ???


All am trying to say here is . There are certainly occassion where
LABELS will make things easier , that's the reason they were
originally created , but there are also occassion where LABELS
will not be as helpfull . Now whether you use labels or not  is
dependent to what you want to accomplish with the hardware and
software combination that you have . Should labels make things easier
then by all means go ahead and use them , should they not then don't
use them .  In my opinion there is no single one trick
( be it labels or whatever ) that will always be there for you when
things start to fall apart .

Kind Regards,
  Kostas



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