home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / unix / bsd / 4224 < prev    next >
Encoding:
Internet Message Format  |  1992-08-15  |  2.1 KB
  1. Path: sparky!uunet!auspex-gw!guy
  2. From: guy@Auspex.COM (Guy Harris)
  3. Newsgroups: comp.unix.bsd
  4. Subject: Re: 386BSD filesystem types. Can I mount a SunOS 4.1.2 disk?
  5. Message-ID: <14082@auspex-gw.auspex.com>
  6. Date: 16 Aug 92 11:34:51 GMT
  7. References: <1992Aug6.052627.22670@zip.eecs.umich.edu> <7087@skye.ed.ac.uk>
  8. Sender: news@auspex-gw.auspex.com
  9. Organization: Auspex Systems, Santa Clara
  10. Lines: 34
  11. Nntp-Posting-Host: auspex.auspex.com
  12.  
  13. >>Hi.  Is the 386BSD filesystem a 4.2 filesystem?  Ie, could I mount
  14. >>a Sun formatted, ... disk?  (Formatted under 4.1.1 or later of SunOS).
  15.  
  16. As noted by Casper Dik, the "Ie" doesn't belong there.  They may both be
  17. 4.2 file systems, but unless the Sun disk came from a Sun386i, the byte
  18. orders differ (and the 386i didn't get a 4.1.1 port).
  19.  
  20. >Note that Sun have made some changes to the file system format which
  21. >may mean that your Sun disk is not a 4.2 filesystem.
  22.  
  23. Well, actually, it ceased being a "4.2" file system in 4.1; it's a
  24. 4.3-tahoe file system there....  (It picked up most 4.3-isms in 4.0,
  25. although directory truncation didn't show up until 4.1.)  However,
  26. 386BSD is presumably also a 4.3-tahoe or later file system.
  27.  
  28. >In particular,
  29. >they introduced something they call "clustering" in 4.1.1.
  30.  
  31. That didn't involve any file system format changes; it's just changes to
  32. the code, so that with "rotdelay" of 0, the UFS code can do sequential
  33. reads and writes in "maxcontig"-sized chunks, rather than in file system
  34. blocks.
  35.  
  36. 4.1.1 file systems with "rotdelay" of 0 and "maxcontig of 7 (7 8K
  37. blocks, or 56KB chunks) should be readable by BSD-file-system code even
  38. if it doesn't support clustering - modulo other file system changes, and
  39. byte-order issues, and the like.
  40.  
  41. Now, one "other file system change" is that the "fs_headswitch" and
  42. "fs_trkseek" fields in the 4.3-tahoe and later superblock are, in SunOS,
  43. an 8-byte file system ID.  The file system id is "currently unused and
  44. unmaintained"; I don't know whether 386BSD uses the "fs_headswitch" or
  45. "fs_trkseek" fields, so this may not be a problem.  (Then again, without
  46. code changes, the byte order is a bigger problem, as noted....)
  47.