l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2005 Apr 18 17:14

The following is an archive of a post made to our 'vox mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox] A philosophical question about partitioning
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox] A philosophical question about partitioning

Bryan Richter said:
> ME wrote:
>> Richard Crawford said:
>> [store music in]
>> > /home/music
>> [where should I store it on a new system]
>> For shared variable data some place under /var. Perhaps make a
>> dir/var/share and in there, make a dir called music
>> /var/share/music
>> (for example)
> I think the problem with that is that music is not 'variable'.

For a shared space on a system, there is a lot of turnover in music files.

Space is finite, you download a song, play it, and download other songs.
Eventually, you delete songs you no longer want to make space for other

>> /var is for variable data.. things like logs, web server roots, file
>> shares that are shared by many users.
>> If you music is shared by many, then a /var sub directory is one of the
>> better choices.
> var != shared.

Though the default webroot in many Linux distros is /var/www which would
seem to violate this convention.

When /var/www is a web root, and a web server is running, and user use
that web server, then many users are sharing files in /var space.

Also, web reports generated from log files are also often stored and
shared from /var as are log files to customers as needed.

> In fact, the FHS doesn't specify a /var/share. /var is
> designed for
> variable data files and "transient and temporary" files --- none of which
> applies
> to music.

temporary depends on timing and what is considered temporary enough to be
variable but not good for /tmp.

For me, 1 month temporary-- about how log I keep songs rotated in when new
songs cause old ones go away.

This is longer than some mbox in /var/spool/mail go without being emptied.

Giving users access to fill up /usr space runs the risk of system or
manual source upgrades failing.

Allowing use of /usr/local/* by user is better than /usr, but is still a
poor choice for source builds, as the admin may need to manage user files
in order to complete an application install.

Use of /var space has also been a convention in many Linux distros for
default web roots, web reports, and as well as a store for mail.

Use of /var space is a convention that has been used for years for things
like those mentioned above.

>> /home should really just be user accounts. Pollution of /home with other
>> dirs that are not usernames can lead to problems when you start adding
>> many users. (As a result, is not a good convention.)
>> Looking at others, and you will see they are not good choices:
>> /tmp (no.)
>> /proc (heh heh. no!)
>> /usr (no. /usr, /usr/share, /usr/src, /usr/local (and other /usr should
>> be
>> used for source an applications and libs-- things that the system uses.)
> Well.. except for /usr/local. The system doesn't touch that.
> And then,
> from the
> FHS, "The /usr/share hierarchy is for all read-only architecture
> independent
> data files" (note how this conflicts with /var). Put those two together
> and you
> get my choice, /usr/local/share/music.

But music directory is not read only. It will continue to grow as users
add more to it.

However, the /var directory may have music files added over time and
deleted over time (much like what you see with maildir for mail storage--
which is located where, when not in the user's home directory space?)

/usr/local/share and /usr/local/share/music still risks problems for
instalation of new software in /usr/local space-- unless there are plans
to creat more partitions.


Not counting a multi-boot system, the above shows the potential for many
partitions for a home user to consider, and exceeding 8 on one drive can
leads to issues of complexity.

> p.s. Actually, /usr/local/share/music is just a symlink on my computer to
> /mnt/nonsys/music. /mnt/nonsys is a big partition with respective
> directories
> for the symlinks /usr/local, /home, /tmp, and some random stuff. That
> seemed
> like a good solution to some of the frustrations I was having with
> partitioning.

This is another alternative, as is the other laternative mentioned to
create a new space in /.

As an admin, I don't think users should be able to write to anything in
the /usr space.
As an admin, I know users have had mbox files stored in /var/spool/mail/
and other files in /var as well (crontab, and other info) and as a result,
they can control addition of content to /var
Allowing users to write to /usr space in addition to /var adds more risk
to administration.

If /var is not liked, then use of another directory in /, or a symlink as
above seem reasonable enough to me.

To me, the function of a directory of music is much closer to how a
maildir directory of mail functions... lots of read only files, added as
needed and deleted as needed.

vox mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Sunset Systems
Who graciously hosts our website & mailing lists!