FreeBSD and FHS summary
Before going back to the FHS list, I'd like to summarize what I think the opinions here were. Please correct me if I'm horribly off-base. The idea of defining a default directory to hold directories for recurring temporary mount points is considered to be a good one, though it's use should be optional. Putting these in / would be a bad idea, because it would clutter up the root directory. Putting these in /mnt would be a bad idea because lots of people expect that directory to be empty to be used for temporary ad hoc mount points. Also, the FHS shouldn't try to define all the names of these mount point directories. Putting this directory into /usr, /tmp, or any of the other well-defined top-level directories doesn't make any sense. But perhaps a directory in /var would be a good idea, but some people thought that it sounded wierd, and there were some technical [1] reasons [2] why it might be a bad idea. Some recommended top-level directories were: /fs, /tfs, /mounts, /volumes, /mnts [1] http://marc.theaimsgroup.com/?l=freebsd-questionsm=106943623518140w=2 [2] http://marc.theaimsgroup.com/?l=freebsd-questionsm=106976168210773w=2 If anyone thinks I would be misrepresenting the discussion, please let me know. Frank ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD and FHS summary
On Tuesday 25 November 2003 9:27, Marc Wiz wrote: May I suggest /tmounts or /tmnts? I'll add them. If people are concerned about lots of directories being created in /'s file system then the top-level directory could itself be a file system. The problem was never about size, but about clutter (ls / shouldn't be to long). It would be nice if the name of the directory could be obtained via sysconf (3). That would be up to the libc folks. Frank ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD, FHS, and /mnt/cdrom
On Saturday 22 November 2003 8:18, Charles Swiger wrote: /mnt should be reserved as a default temporary mount point-- it's silly to risk breaking existing tools or procedures. Anyway, I suggest you solicit feedback from Solaris users and possibly MacOS X people as well. Solaris features vold (implied by wanting to use /vol), and the latter OS places temporary removable mountpoints under /Volumes. The point that /mnt should be left alone is pretty clear, but I'm glad to be able to say Folks on the FreeBSD questions list agree. As for Mac OS X, they have no intention of being FHS-compliant, so while we may learn some lessons from them, they won't worrz about what we have to say. I happen to think that OS X handles things well from a user interface standpoint-- the Finder in Panther with Miller column display and an eject symbol next to the volume name, but I'm not sure how relevant that is. Frank, is your group's standard concerned about physical volume names, logical volume names intended for human identification/access, or both? Physical device names ought to have unit numbers or even be part of a tree-like device hierarchy-- for instance, what does /cdrom refer to in a machine with two CD-ROM devices? In the current version of the standard (2.2), nothing. But in the next revision, /foo/cdrom will be a symlink to /foo/cdrom0, and /foo/cdrom1 won't have a link. Managing these links is not the scope of the standard (yet). The priority for the next revision is to define what /foo should be. Human-readable names also run the risk of two removable devices having the same name; people are happy seeing a list containing duplicate names (eg, particularly if one name has a CDROM icon next to it, and the other has a floppy or USB pen icon :-), but that doesn't tell you what to do with your filesystem hierarchy layout. The actual names of the directories will be undefined, but there will be some suggestions (cdrom, floppy, etc.) Obviously, a standard that says place mount points anywhere you want isn't very useful. But if you did come up with a standard, who should follow it and what would they gain? As for who should follow it, Linux distributions (Debian, Red Hat, SuSE) as well as the *BSDs (though I'm not sure exaclty what that means in the BSD world). What would be gained is more for application support. Basically, xmms and xcdroast could configure a /foo/cdrom as a default location, and it will be correct for all FHS-compliant systems. Frank ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD, FHS, and /mnt/cdrom
The folks at the Filesystem Hierarchy Standard (FHS) are discussing (again) where directories for recurring temporary mount points should go. Recurring temporary mount points are for things like cdroms, floppies, and digital cameras as well as HD partitions from other OSes (like MS Windows). Red Hat started putting these in /mnt (e.g. /mnt/cdrom), but that totally breaks compatibility with the BSDs, which have specified /mnt as an empty directory for ad hoc temporary mounts. SuSE has started putting these in /media, and now folks on the FHS list would like to know what people in the BSDs' communities would prefer. I imagine your answer will be something like We don't care; do what you want, but I would like to present the different ideas, and perhaps you would prefer one. So, please put these in the order of most to least preferred, and say why you like or dislike any of them. - All mount points in / (e.g. /cdrom, /camera, /windows/C) - current FreeBSD standard - All mount points in /mnt (e.g. /mnt/cdrom, /mnt/camera, /mnt/windows/C) - breaks FreeBSD standard for an empty /mnt - Anyplace at all - Anyplace but /mnt (i.e. what the FHS 2.2 currently specifies) - Anyplace but / or /mnt (e.g. /vol/cdrom, /var/mnt/camera, /media/windows/C) (some suggestions have been /media, /mounts, /vol, /var/mnt, and /var/tmp/removable. Others?) Thanks letting us know how you feel about this, Frank Murphy -- http://www.fastmail.fm - And now for something completely differentÂ… ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD, FHS, and /mnt/cdrom
On Fri, 21 Nov 2003 10:07:31 -0500 (EST), Jerry McAllister [EMAIL PROTECTED] said: Good: - All mount points in / (e.g. /cdrom, /camera, /windows/C) - current FreeBSD standard (Just come up with a nice sounding name for each) The problem isn't what the names of the directories are, but where they belong. The idea is to be flexible enough that any new device that shows up can be put into a sensible directory, not to define nice sounding names for each new device that comes along. That will be decided by distributions and application developers over time (outside of the FHS). - Under something like /media/as in /media/cdrom, etc (except the name media may become obsolete) - Anyplace but /mnt (i.e. what the FHS 2.2 currently specifies) Except not /var/ or /usr or /home or /tmp I understand why not /usr, /home, or /tmp, but why not someplace in /var? These are specifically temporary mount points, and the FreeBSD hier(7) manpage defines /var to be: /var/multi-purpose log, temporary, transient, and spool files Less Good: - All mount points in /mnt (e.g. /mnt/cdrom, /mnt/camera, /mnt/windows/C) - breaks FreeBSD standard for an empty /mnt NOT: These are too long and cumbersom, may contradict other usage Especially not /var... as it is something else and /media/windows... is also too MS specific. The windows part was just an example which won't be in the standard. You say especially not /var because it's something else. What is it, do you think? - Anyplace but / or /mnt (e.g. /vol/cdrom, /var/mnt/camera, /media/windows/C) (some suggestions have been /media, /mounts, /vol, /var/mnt, and /var/tmp/removable. Others?) Anyplace at all Now, that is not much of a standard - why bother? Well, the idea would be that the standard wouldn't bother. :) It sounds like you think that a new root-level directory should be created for this, and that /media would be OK, but there might be a (yet undiscovered) better name. Is this accurate? Thanks for responding to me, Frank -- http://www.fastmail.fm - Faster than the air-speed velocity of an unladen european swallow ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD, FHS, and /mnt/cdrom
It sounds like you think that a new root-level directory should be created for this, and that /media would be OK, but there might be a (yet undiscovered) better name. Is this accurate? That seems like a pretty good summary. jerry Cool. Could you also explain to me why you think that /var would be such a bad place for this? Frank -- http://www.fastmail.fm - Send your email first class ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD, FHS, and /mnt/cdrom
On Friday 21 November 2003 6:36, Jerry McAllister wrote: Could you also explain to me why you think that /var would be such a bad place for this? Well, I probably can't give a hard and fast absolute reason, but... We use /var as a place for directoreis/files that can grow somewhat unexpectedly and weakly controlled, such as spool and logs, etc. Because of that, our /var is most often put in some other large general filesystem with links and doesn't really live in either root (/) or isn't a root located filesystem, but just a directory in another filesystem such as /work (or in some recent ones /lump - I couldn't think of a better name). So, making it the home of mount points would be rather awkward. I suspect that some others do similar things with /var. I have heard it mentioned. I think something similar can be true of other root located file systems such as /usr, although for those it is more likely that it just be a directory living within /usr that gets moved and linked. One of the ideas behind this new directory of mount points is that some kind of automounter could then create and delete directories someplace as needed without affecting anyone. So while not as large in K as a logfile, the contents of the directory could get pretty large. (Probably a realistic max of 20 items, but enough to rule out leaving it in /.) Just because /var is a symlink to /lump/var shouldn't affect that. Generally, I think mount point directories should be as close to root located as possible with as little intervening stuff that could possible get shuffled around. At first blush, it would sound like /mnt would be a likely place, but it has been out there too long and been used in too many locally unique ways that mounts on or in there could create much unnecessary confusion. I agree. I'd prefer to use /mnt for this, but with the historical usages, it's not really possible. As far as any ol' where goes, that doesn't bother me much, but it sounds like what is being asked for is a kind of common place that won't cause problems so vendors and third party writers can go ahead and make something that will work easily across platforms with the least pain - and ain't that what everyone whines so much about - the pain of adding devices, etc.This would be a harmless way to ease some of that pain. And, anyway, if a standard location is adopted and if some users want to do it differently on their machines nothing would stop them from doing whatever they want with their systems. It would be no worse than if there was no standard and probably easier. Exaclty. Just lets not break a bunch of stuff to do it. Gee, it's nice to be asked about something like this for a change. That's why I wanted to ask. Find out how other people are doing this. Frank ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
