Maurice Castro wrote: > Hi All, > the separating of /var is something that comes from the Unix > tradition. Much of the Unix tradition of systems administration is > based on making sure systems with many users remain stable and so > administrators are prepared to work to make the system more reliable. > Common Windows, Linux and OS X practices are dominated by the concept > of a personal computer ie you only hurt yourself so ease is a priority > to them. >
So the consensus is that if we are to compete with them at the desktop, then a simpler, easier to maintain file system structure is cool. > The original filesystem layout separated > / > /var > /tmp > /usr > onto separate filessytems. In the bad old days every time there is a > write there is risk that the filesystem may be made unstable so the > aim was to minimise writes to / as without / booting to a minimal > environment is a serious trial. > Actually, no. There was /. /var didn't show up until SunOS 4 circa 1988. /usr was made separable when it began to grow bigger than the disks available at the time, circa 1986 or so. In any case, well after UNIX was established. > /tmp was used for data that is not required to persist over reboots. > /var was used for data that should persist over reboots > > The other filesystems were used to store user files / non-minimal boot > programs etc > > By separating the filesystems it is possible to make a far more > recoverable system in the event of: > - a user deciding to fill up all of one piece of temporary storage > (ramdisk /tmp was one of those optimisations that sun made that had > some serious negative consequences; many admins on large shared > systems make it back into a disk backed filesystem) > - high write rate to other filesystems reduces risk of boot affecting > writes from being made > The reason for separating was very different, though this was also a side-product. In the days of diskless systems, you could share parts of the OS as read-only. /usr originally contained /usr/tmp and /usr/Richard (or whatever). To make /usr be read-only, user home directories and tmp had to be moved out to /var. / also was unique to each diskless client, so while they could share much of the stuff in /usr, each had to have its own /. Some people also took advantage of the fact that /usr/spool is now in /var/spool, where the printer files and mail collected and separated these out so that you wouldn't have to back them up (tapes were 60MBytes or so at the time). So, there you have it: /, /var, /usr, and /export/home. Each has a different policy, which is the key here. NB. UFS, by default, reserves 10% which only root can write. So a regular user could not directly impact a running UNIX system using UFS. ZFS does not have such reserve, so if you want to implement it, you will end up with a separate file system somewhere. -- richard > So keeping /var and /tmp separate make life much easier. Some of us > have even been known to run with a read-only root filesystem. > > Linux and windows users appear to value the flexibility of not having > to make system use decisions ie how big /var and /tmp should be at > installation and being able to use the disk as they see fit; however, > they are typically not managing systems for others and so they have > made a choice of convenience which can be seriously inconvenient in a > shared environment. > > Maurice Castro > > On 24/06/2008, at 10:45 AM, Richard Elling wrote: > > >> I think the ability to have different policies for file systems >> is pure goodness -- though you pay for it on the backup/ >> restore side. >> >> A side question though, my friends who run Windows, >> Linux, or OSX don't seem to have this bias towards isolating >> /var. Is this a purely Solaris phenomenon? If so, how do we >> fix it? >> -- richard >> > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
