[vox] A philosophical question about partitioning
ME
dugan at passwall.com
Mon Apr 18 16:19:25 PDT 2005
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
songs.
>> /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.
/
/home
/usr
/usr/local
/usr/local/share
/usr/local/share/music
/var
/tmp
swap
/boot
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.
More information about the vox
mailing list