Cannot umount /usr filesystem (ALWAYS "busy")

Conor P. Cahill cpcahil at virtech.uucp
Thu Jun 14 11:31:14 AEST 1990


In article <1990Jun13.184338.26482 at pmafire.UUCP> rickf at pmafire.UUCP (rick furniss) writes:
>
>  Be it by design or what ever, using /usr as a non-root filesystem will
>create some problems that need to be addressed.

I hate to burst your bubble, but root has always been designed to be very
small and include only thos programs that are needed to get the system running.

This did not include things on /usr.  /usr was and is, on many systems, a 
mounted file system.  

My first experience with a combined root/usr was with pc based unix systems.

>  I stand by my guns, /usr was never originaly designed as a non-root FS.

Yes it was.  your experience with xenix and at&t unix (not sure what you mean
by at&t unix) is not representative of the entire unix market.  I have worked
on Version 6, PWB, System III, System V.* and the vast majority of systems
have a /usr partition that is not part of root.

>  SU, or single user modes have minimal requirments so that multiuser mode
>can be configured, fixed, or made ready.

That is why /usr is not needed.

>  Over the years as Unix become widely used, & heavely loaded, /usr started
>to become overloaded creating a root FS that was too large for speed / Inode
>reasons.  Most people took two routes to unload the burden from /usr.

If you had worked in an OS shop you would know that whenever a new command is
to be added to the system a conscious decision has to be made as to whether
or not it is needed on /.  The "test" as to whether it is needed on root is
usually "do I need it in single user mode?".

>(1) Create a second /user, /u, /users partition leaving /usr for
>    system programs & users.
>(2) Made /usr a mountable seperate FS

The breakup of a system into filesystems has many other reasons including
the ease of administration, separation of different groups of users, 
ease of backing up separate file systems (especially when dd copies of
file systems was the standard mechanism for backup/restore).



-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.,
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170 



More information about the Comp.unix.i386 mailing list