Unix Technical Forum

/var/mail -vs- /var/spool/mail

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 ...


Go Back   Unix Technical Forum > Unix Operating Systems > Linux Operating System

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #11 (permalink)  
Old 01-18-2008, 08:28 AM
phil-news-nospam@ipal.net
 
Posts: n/a
Default Re: /var/mail -vs- /var/spool/mail

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/hda3pt 4075456 3712760 362696 92% /opt
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/hda3pt /opt ext2 ro,noatime 0 0
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/ |
-----------------------------------------------------------------------------
Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #12 (permalink)  
Old 01-18-2008, 08:30 AM
Jeff Makey
 
Posts: n/a
Default Re: /var/mail -vs- /var/spool/mail

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
Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #13 (permalink)  
Old 01-18-2008, 08:30 AM
phil-news-nospam@ipal.net
 
Posts: n/a
Default Re: /var/mail -vs- /var/spool/mail

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/ |
-----------------------------------------------------------------------------
Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On
Forum Jump


All times are GMT. The time now is 01:08 PM.


Powered by vBulletin® Version 3.6.5
Copyright ©2000 - 2009, Jelsoft Enterprises Ltd.
Search Engine Optimization by vBSEO 3.2.0
www.UnixAdminTalk.com