home *** CD-ROM | disk | FTP | other *** search
/ Amiga GigaPD 3 / Amiga_GigaPD_v3_3of3.iso / netbsd / docs / mailinglist-archive / 1993-12 / text0444.txt < prev    next >
Encoding:
Text File  |  1993-06-25  |  3.0 KB  |  70 lines
  1. Well, now that there are multiple mailing lists for NetBSD, I'm not
  2. sure this is the right place for this...
  3.  
  4. I've been using the IBM RS/6000 lately and I've come to respect the
  5. Logical Volume abstraction for allocation of disk space (other things
  6. cause no end of annoyance, but..)  This message is to ask about the
  7. possibility of including state-of-the-art disk space management
  8. technology into NetBSD-Amiga.
  9.  
  10. Basically, their "LVM" product (Logical Volume Manager) creates the
  11. idea of a virtual disk drive in which disk space need not be allocated
  12. contiguously.  Since the "virtual drive" is really multiple drives,
  13. the space does not even need to be on a single drive.  In addition,
  14. since the LVM is a layer between the /dev/hdxx software interface and
  15. the physical device drivers, filesystems can be extended dynamically
  16. *while the filesystem is mounted and in use*!!  (Of course, shrinking
  17. them back again is a might bit more difficult :-)  Mirroring can be
  18. done at this level also, in which case the LVM simply puts the disk
  19. buffer into two device driver queues instead of one.
  20.  
  21. Using IBM terminology (ugh!), multiple "physical volumes", ie. disk
  22. drives, are organized together into "volume groups".  All allocations
  23. take place within a volume group so a filesystem can't be larger than
  24. a VG.  The VG is a software entity and does not need to be on a single
  25. SCSI adapter or whatever.  Each PV is broken down into chunks of a
  26. given size (usually 4MB on the rs6k) and this size becomes the minimum
  27. unit of allocation.
  28.  
  29. For instance, the default installation of the rs6k creates a single
  30. VG, "rootvg".  The required filesystems are put into this VG:  / (root),
  31. /usr, /tmp, /var, and /home.  Paging space and the dump device are also
  32. allocated at install time, but don't have filesystems on them as the
  33. others do.
  34.  
  35. The above scenario would result in an entry in /dev for each logical
  36. volume:
  37.  
  38.     Device Name:    Filesystem Used For:
  39.     /dev/hd1    /usr
  40.     /dev/hd2    /tmp
  41.     /dev/hd3    /home
  42.     /dev/hd4    /
  43.     /dev/hd5    /blv (used only to hold the boot image stuff)
  44.     /dev/hd6    paging space
  45.     /dev/hd7    dumpdev
  46.     /dev/hd8    logdev (for journalled filesystems)
  47.  
  48.     /dev/hdisk0    access to raw disk drive
  49.         :
  50.         :
  51.  
  52. This scheme works fairly well.  FSCK and friends can still access
  53. /dev/whatever to do their job, the mount command still uses the same
  54. syntax, etc.  But when the system gets low on space in a given
  55. filesystem, it can be dynamically extended by grabbing space from the
  56. part of the VG that hasn't been allocated yet.  So the ideal strategy
  57. is to not allocate space unless you need it.  That way there will be
  58. unallocated chunks that can be used later as needed.
  59.  
  60. Anyway, this is the software that the OSF has adopted.  It provides a
  61. good layer of insulation from the hassles of disk space management and
  62. filesystem quirkiness.
  63. --
  64. Frank "Crash" Edwards    Edwards & Edwards Consulting
  65. Voice: 813/786-3675      Unix/AIX & OS/2: Training, Programming, and SysAdmin
  66. Data:  813/787-3675      crash@azhrei.EEC.COM
  67.     "You can't have everything.  Where would you put it?"
  68.         -- Steven Wright
  69.  
  70.