This is a discussion on /var/mail -vs- /var/spool/mail within the Linux Operating System forums, part of the Unix Operating Systems category; --> On 21 Apr 2005 21:30:15 GMT Jeff Makey <jeff@sdsc.edu> wrote: | It isn't important which of /var/mail and /var/spool/mail ...
| |||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| ||||
| On 21 Apr 2005 21:30:15 GMT Jeff Makey <jeff@sdsc.edu> wrote: | It isn't important which of /var/mail and /var/spool/mail is the | real directory and which is the symbolic link pointing to the other. | I recommend leaving it set up however your distribution does it in a | standard installation so package updates don't get confused. If you | really want to optimize, however, you could survey the tools you use | that access the mail spool directly (/bin/mail, pine, IMAP server, | etc.) and make the most popular path the real directory. I'm changing the way the directories are set up and mounted. It is a bit more complicated to mount /var/spool/mail than it is to mount /var/mail. because my init code would have to check to see how /var/spool is handled. Mounting /var/mail would be easier. Yet what I do see is that most apps access /var/mail instead of /var/spool/mail, and /var/mail is a symlink as Slackware installs it. The way I am doing this is instead of one disk filesystem being the root, the root will be either the original rootfs the kernel first mounts, or a tmpfs mounted over it. Then each filesystem will be mounted in a temporary place. Then each directory of those filesystems that is to be mounted will be mounted with the --bind option to the intended mount point. This will result in a number of mount points going to the same filesystem. For example directories /bin /lib /opt /sbin and /usr will come from a r/o filesystem where the system is installed. Other mount points will come from other filesystems. Each of these filesystems will all be relative to / instead of relative to their mount point (since there is more than one mount point). The /dev directory will be populated from scanning for "dev" entries in the sysfs filesystem at /sys. The /etc directory will be populated by copying files from a designated location instead of mounting it. In the future this may be done from a network source. It may be a tmpfs filesystem to facilitate this. Some others will be tmpfs. Here is what my df output looks like so far: Filesystem 1K-blocks Used Available Use% Mounted on tmpfs[root] 1024 0 1024 0% / /dev/hda1 248944 162972 85972 66% /admin /dev/hda3:bin 4075456 3712760 362696 92% /bin /dev/hda1:boot 248944 162972 85972 66% /boot /dev/hda5:dev 128440 103140 25300 81% /dev devpts 0 0 0 - /dev/pts tmpfs[shm] 193036 0 193036 0% /dev/shm /dev/hda5:etc 128440 103140 25300 81% /etc /dev/hda4:home 113631392 110765312 2866080 98% /home /dev/hda3:lib 4075456 3712760 362696 92% /lib /dev/hda3 proc 0 0 0 - /proc /dev/hda5:root 128440 103140 25300 81% /root /dev/hda3:sbin 4075456 3712760 362696 92% /sbin sysfs 0 0 0 - /sys /dev/hda7:tmp 642536 38288 604248 6% /tmp /dev/hda3:usr 4075456 3712760 362696 92% /usr /dev/hda5:var 128440 103140 25300 81% /var tmpfs[lock] 193036 0 193036 0% /var/lock /dev/hda8:log 128440 47976 80464 38% /var/log tmpfs[run] 193036 52 192984 1% /var/run /dev/hda6:var/mail 128440 32840 95600 26% /var/mail /dev/hda7:var/tmp 642536 38288 604248 6% /var/tmp /dev/hda4:web 113631392 110765312 2866080 98% /web This is how /proc/mounts shows it: rootfs / rootfs rw 0 0 root / tmpfs rw 0 0 /dev/hda1 /admin ext2 ro,noatime,nosuid 0 0 /dev/hda3 /bin ext2 ro,noatime 0 0 /dev/hda1 /boot ext2 ro,noatime,nosuid 0 0 /dev/hda5 /dev reiserfs rw,noatime 0 0 devpts /dev/pts devpts rw,nosuid,noexec 0 0 shm /dev/shm tmpfs rw,nosuid,nodev,noexec 0 0 /dev/hda5 /etc reiserfs rw,noatime 0 0 /dev/hda4 /home reiserfs rw,noatime 0 0 /dev/hda3 /lib ext2 ro,noatime 0 0 /dev/hda3 /opt ext2 ro,noatime 0 0 proc /proc proc rw,nodiratime,nosuid,nodev,noexec 0 0 /dev/hda5 /root reiserfs rw,noatime 0 0 /dev/hda3 /sbin ext2 ro,noatime 0 0 sysfs /sys sysfs rw,nosuid,noexec 0 0 /dev/hda7 /tmp reiserfs rw,noatime,nosuid,nodev 0 0 /dev/hda3 /usr ext2 ro,noatime 0 0 /dev/hda5 /var reiserfs rw,noatime 0 0 lock /var/lock tmpfs rw,nosuid,nodev,noexec 0 0 /dev/hda8 /var/log reiserfs rw,sync,noatime,nosuid,nodev,noexec 0 0 run /var/run tmpfs rw,nosuid,nodev,noexec 0 0 /dev/hda6 /var/mail reiserfs rw,nosuid,nodev,noexec 0 0 /dev/hda7 /var/tmp reiserfs rw,noatime,nosuid,nodev 0 0 /dev/hda4 /web reiserfs rw,noatime 0 0 This is how /etc/mtab shows it: tmpfs[root] / tmpfs ro,nosuid,nodev,noexec 0 0 /dev/hda1 /admin ext2 ro,noatime,nosuid 0 0 /dev/hda3:bin /bin ext2 ro,noatime 0 0 /dev/hda1:boot /boot ext2 ro,noatime,nosuid 0 0 /dev/hda5:dev /dev reiserfs rw,noatime 0 0 devpts /dev/pts devpts rw,nosuid,noexec 0 0 tmpfs[shm] /dev/shm tmpfs rw,nosuid,nodev,noexec 0 0 /dev/hda5:etc /etc reiserfs rw,noatime 0 0 /dev/hda4:home /home reiserfs rw,noatime 0 0 /dev/hda3:lib /lib ext2 ro,noatime 0 0 /dev/hda3 proc /proc proc rw,nodiratime,nosuid,nodev,noexec 0 0 /dev/hda5:root /root reiserfs rw,noatime 0 0 /dev/hda3:sbin /sbin ext2 ro,noatime 0 0 sysfs /sys sysfs rw,nosuid,noexec 0 0 /dev/hda7:tmp /tmp reiserfs rw,noatime,nosuid,nodev 0 0 /dev/hda3:usr /usr ext2 ro,noatime 0 0 /dev/hda5:var /var reiserfs rw,noatime 0 0 tmpfs[lock] /var/lock tmpfs rw,nosuid,nodev,noexec 0 0 /dev/hda8:log /var/log reiserfs rw,sync,noatime,nosuid,nodev,noexec 0 0 tmpfs[run] /var/run tmpfs rw,nosuid,nodev,noexec 0 0 /dev/hda6:var/mail /var/mail reiserfs rw,nosuid,nodev,noexec 0 0 /dev/hda7:var/tmp /var/tmp reiserfs rw,noatime,nosuid,nodev 0 0 /dev/hda4:web /web reiserfs rw,noatime 0 0 /home/local /usr/local bind rw,bind 0 0 The above is the version set up by running a preinit program as init. Right now /etc isn't copied in this version, but it will be in the early userspace version I am working on next. This is all experimental. But the idea is to reduce the number of filesystems while still getting each mounted where it needs to be, and still having the differences that make separate filesystems essential. -- ----------------------------------------------------------------------------- | Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ | | (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ | ----------------------------------------------------------------------------- |
| |||
| In article <d499cu01su9@news4.newsguy.com>, <phil-news-nospam@ipal.net> wrote: >This is all experimental. But the idea is to reduce the number of >filesystems while still getting each mounted where it needs to be, >and still having the differences that make separate filesystems >essential. Your approach creates a lot of complexity. It seems to me that it would be much simpler to do an ordinary mount of one file system of each policy, and then sprinkle symbolic links as needed to make all of the existing paths work. Nevertheless, I encourage you to prove me wrong by finding a brilliant new way of organizing the file system hierarchy. Good luck with your experimentation. :: Jeff Makey jeff@sdsc.edu Department of Tautological Pleonasms and Superfluous Redundancies Department |
| ||||
| On 27 Apr 2005 01:45:35 GMT Jeff Makey <jeff@sdsc.edu> wrote: | In article <d499cu01su9@news4.newsguy.com>, <phil-news-nospam@ipal.net> wrote: |>This is all experimental. But the idea is to reduce the number of |>filesystems while still getting each mounted where it needs to be, |>and still having the differences that make separate filesystems |>essential. | | Your approach creates a lot of complexity. It seems to me that it | would be much simpler to do an ordinary mount of one file system of | each policy, and then sprinkle symbolic links as needed to make all of | the existing paths work. Nevertheless, I encourage you to prove me | wrong by finding a brilliant new way of organizing the file system | hierarchy. Good luck with your experimentation. I've done it that way before. There were some problems that resulted from the fact that these were symlinks. When the bind-mount feature came along, that created the solution. So instead of a symlink, I use a bind mount. If you count the symlink as 1 unit of complexity, and each bind mount as 1 unit of complexity, it comes out the same. The development of the early userspace handling in the kernel is also a usable feature. -- ----------------------------------------------------------------------------- | Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ | | (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ | ----------------------------------------------------------------------------- |