Hi, >>"Ted" == Theodore Y Ts'o <[EMAIL PROTECTED]> writes:
Ted> I keep hearing people claim that distribution folks are saying "ick", Ted> but I haven't heard any technical reasons besides, "Moving spool Ted> directories is hard". Fine. Here are a few. I, and a number of other sysadmins, have a partition for /var, and mount /var/spool on it. The understanding has always been that */spool/ directories contain data that may grow unpredictably. If I use log rotation, and purge old logs regularly, /var remains a more or less static in size, apart from the spool directories. One has little control over the size of the spool directories. So, one puts the spool directory on another partition. This has been standard practice in OS's derived from BSD, I think (I know we used to do it on Ultrix, in the good old days). Another factor is wehen the spool directories are used for USENET or mail, there are a large number of small files with a high turnover; one some file systems one may tweak parameters to make the file system better suited for spools. (This is certainly less true for mail than for news, but still) I have generally put large partitions for spool, and prefer not to have an overfull spool partition bring down the system. Ted> When I and others have pointed out that moving the spool Ted> directory isn't required; just a symlink, I have heard dead Ted> silence. So the lack of technical discussion, but just a Ted> stony-silence "No!" is rather disappointing as far as I'm Ted> concerned. I have no objections to a compatibility link in /var/mail, or to modifying code to look in both places. Ted> I think we should require that new applications use /var/mail, Ted> and that backwards compatibility symlinks should exist. While the new FHS is trying for conformance with other unices, we should also consider rtadition (traditionally, /var/spool/mail has been the location for Linux boxes) Why can't we get compatibility with the so called other unices just by putting in a sym link in /var/mail, and leaving the spool directory where it is? Ted> If we must back out /var/mail (for no good technical reason that I can Ted> determine), then at the very least I think we should state that there Ted> that for all compliant distributions, /var/mail *MUST* be a valid way of Ted> reaching the spool directory (i.e., there should be a symlink there, or Ted> where the spool directory actually lives) and that it be permissible for Ted> applications to use /var/mail to find the mail directory (but that Ted> applications that want to keep using /var/spool/mail would not be Ted> considered obsolete). I think this is a reasonable compromise. Ted> At least that way applications that want to use the same dirctory as the Ted> vast majority of other Unix systems will work without needing a special Ted> case for Linux. However, I would much rather see us adopt the full, Ted> correct solution, rather than this half-measure. This is the first rationale I have seen for actually going to /var/mail, other than ``those other unices do it'', and I think a symlink shall address all those concerns quite well. I suppose there sould also be an argument that the mail spool is not really a spool, but a message queue still qualifies for being on the spool partition. (trying to move my mail spool directory to /var/mail may well fail on some of my machines due to file system getting overfull) I have not being following the FHS list, so these opinions may well be un informed. manoj -- +#if defined(__alpha__) && defined(CONFIG_PCI) /* The meaning of life, the universe, and everything. Plus this makes the year come out right. */ year -= 42; +#endif (From the patch for 1.3.2: (kernel/time.c), submitted by Marcus Meissner) Manoj Srivastava <[EMAIL PROTECTED]> <http://www.golden-gryphon.com/> Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E