OT: redhat

[Bill Campbell]

On Sun, Nov 14, 2004, Bill Vermillion wrote:
>On Sat, Nov 13 15:01 , Bill Campbell, showing utter disregard for 
...
>> I think that AIX is based on the Veritas file system which has
>> many neat features including ``freezing'' a partion for backup
>> while journalling changes which can then be used to update the
>> frozen system. Veritas has been ported to systems other than
>> AIX.
>
>Was Veritas around when AIX came out?  I remember when IBM
>introduced the RS6000 and AIX.  They were proud of SMIT [for
>administration] and the ability to grow filesystem on the fly.
>Things that are much more imortant now than they were 10 years ago.

I think that Veritas was the original developer of the logical file
systems, but my AIX experience is very limited (my sysadmin experience on
AIX is virtually nonexistent).

....
>> There can only be four ``primary'' partitions using PC standard
>> partitioning or three primary and an ``extended'' partition which can
>> contain multiple logical partitions.
>
>And it depends upon the OS running on top of the drive if you can
>use logical partitions.  Given the BSD heritage going back to
>the late 1970s - it does't like logical partitions.  But the
>logical partitions were the MS invention to handle drives
>that were bigger than fileystmes that the default OS could handle.

Typically Linux recognizes the extendeded partitions, and the grub boot
loader is happy to boot off of them.  I've never tried anything fancy on
FreeBSD beyond creating a vinum file system that spans multiple SCSI disk
drives as a concantenated file system.  Frankly I'm much more comfortable
with Linux systems than FreeBSD, largely because I've had much more
experience with Linux.

>Remember the FAT12.  And remember when you could only have
>about 512 files total.  [I think it was 512 - it may have been
>slightly different].  THen came 16 bit fat and of course the 2GB
>limits were there.  So you made three 2GB partitions, and then
>took whatever was left and made as many logical partitions to use
>up the drive space.

Microsoft's first ``solution'' to large file systems was to crank up the
segment size which increased the total size without increasing the number
of segments.  One effect was to waste large amounts of disk space because
of inefficient storage.

>So many of those limits are gone now.  Remember when the OS for
>booting had to like within the first 1024 cylinders.  When you look
>at the current FreeBSD booting limits you wonder how we survived so
>long with the old limits.  In the 5.x and 6.x FreeBSD the booting
>code has to lie withing the first 1.5 Terabytes of the first
>filesystem.  The first filesystem does not have to be limited to
>that amount, just the the boot code must like in the first 1.5TB of
>it.

The grub boot loader was the first Linux loader to allow booting partitions
beyond the first 1024 cylinders with LILO not far behind.

>> The more advanced systems such as vinum and LVM can span
>> partitions and/or hard drives so there's no physical
>> limitation.
>
>But there is the possible problem of losing a drive in a spanned
>system.  But with the 400GB drives now available that should only
>be a problem on really large systems, and then you will most likely
>use a RAID system as a spanned FS with no RAID recovery could be
>a long time to restore - even with the fast systems.

RAID has its own problems, mostly related to OS driver support (unless one
uses purely hardware RAID as in extern RAID controllers that connect to
standard SCSI controllers independent of the underlying Operating System).
Fundamentally you run into the problem of ``putting all your eggs in one
basket'' when dealing with spanned file systems.  RAID 5 and it's
descendants permit one to replace failed drives without data loss, but the
concatenated file systems don't.  How much data do you want to have to
recover in the case of a hard drive failure?

>> >Each partition must occupy contiguous disk space.  So to
>> >use space on more than one partition [BSD slice] that are not
>> >physically adjacent the fileysystem creation programs would handle
>> >that at the logical level.  I don't see the need for having to
>> >physically join partitions to make a file system if you can
>> >logically create a filesystem spread over more than one
>> >physical partition.
>
>> The only time I've used LVN on Linux to join disk partitions
>> was to join two 2gb partitions into a 4gb logical partition
>> where I didn't want to change the partitions with fdisk for
>> fear of breaking things that knew about the partition numbers.
>
>That makes sense.  Does Linux still change the numbers if you
>remove a drive in the middle - say you had 4 drives and removed one
>- do the drives above the middle one get renumbered.  That used to
>be a problem but I'm not that deep into Linux at the moment.

I'm not sure what Linux does when a partition is removed, and I really
didn't want to find out the hard way which is why I use LVM.

Bill
--
INTERNET:   bill at Celestial.COM  Bill Campbell; Celestial Software LLC
UUCP:               camco!bill  PO Box 820; 6641 E. Mercer Way
FAX:            (206) 232-9186  Mercer Island, WA 98040-0820; (206) 236-1676
URL: http://www.celestial.com/

``Nobody wants to be called common people, especially common people.''
    Will Rogers