Content deleted Content added
Guy Harris (talk | contribs) →Tmpfs limitations: I.e., don't discuss details of tmpfs in the article at all? Sounds good to me. |
m Fix Linter errors. |
||
| (25 intermediate revisions by 11 users not shown) | |||
Line 1:
{{WikiProject
{{WikiProject Computing |importance=Mid |science=y |science-importance=Mid |software=y |software-importance=Mid}}
{{WikiProject Linux |importance=Mid}}
}}
== /sbin's name ==
Pretty sure that sbin intially stood for static linked binaries. <span style="font-size: smaller;" class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/173.55.202.3|173.55.202.3]] ([[User talk:173.55.202.3|talk]]) 08:16, 3 May 2012 (UTC)</span><!-- Template:Unsigned IP --> <!--Autosigned by SineBot-->
:Given that <
::I always understood it to mean "system administration binaries", but I can't remember ever having an explicit explanation of the name. [[User:Qwertyus|Q<small>VVERTYVS</small>]] <small>([[User talk:Qwertyus|hm?]])</small> 23:16, 19 November 2013 (UTC)
:::I have the impression that ("system administration", or something such as that) was what the "s" meant. [[User:Guy Harris|Guy Harris]] ([[User talk:Guy Harris|talk]]) 00:09, 20 November 2013 (UTC)
== /usr/libexec is in FHS ==
Line 18:
http://www.linuxbase.org/betaspecs/fhs/fhs/ch04s07.html
:That URL has "betaspecs" in it; [http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#THEUSRHIERARCHY the /usr section of the 2.3 version of the FHS] doesn't mention <
== So where did /sbin, /usr/sbin, and /var come from? ==
Actually, unless my memories are too faded, I ''know'' where they came from - some people at Sun, around the time SunOS 4.0 was being developed, were making some changes to the directory layout, oriented towards NFS-only diskless workstations (when Sun were killing of the ND remote-disk-access protocol), and one of the changes was the introduction of <
I seem to remember a document written describing this, and possibly even being circulated outside Sun (possibly amongst licensees of NFS and/or the BSD folk). However, I can't seem to find any trace of that document online. Anybody have less-faded memories than mine? [[User:Guy Harris|Guy Harris]] ([[User talk:Guy Harris|talk]]) 01:26, 17 November 2013 (UTC)
:I don't have the document you want, but wouldn't <
::(<
::Yeah, I think that was another reason for creating <
::I think the split between <
::But this is all fading memories from the mid '80's, which is why I wish the stuff the Sun folks had written about this was available somewhere. [[User:Guy Harris|Guy Harris]] ([[User talk:Guy Harris|talk]]) 20:16, 18 November 2013 (UTC)
Line 39:
[[Special:Contributions/174.46.232.2|174.46.232.2]] ([[User talk:174.46.232.2|talk]]) 18:19, 3 April 2014 (UTC)
:That was the original split. The directory layout was changed in SunOS 4.0, with <
== Other Unices, other filesystems ==
Line 63:
::I.e., for /tmp, just say something such as "A place for temporary files that do not have to survive a reboot.", with the possible addition of a brief mention of the possibility of it being a tmpfs file system, with a link to [[tmpfs]], and nothing about the characteristics of tmpfs? Sounds good to me. [[User:Guy Harris|Guy Harris]] ([[User talk:Guy Harris|talk]]) 20:28, 27 March 2015 (UTC)
:::Sorry, have seen your post here a little late. It would seem that we are approximately in agreement that tmpfs is somehow limited by (size of RAM + size of swap) and although the details of this restriction are different on every platform and can be usually tweaked by the sysadmin it may be a significant enough restriction that it could be at least mentioned here. [[User:Richiez|Richiez]] ([[User talk:Richiez|talk]]) 12:44, 28 March 2015 (UTC)
::::Yes, like all file systems, tmpfs is going to be limited by the amount of backing store it has. I've used systems where a disk-based {{mono|/tmp}} had less space than {{mono|/{usr,var}/tmp}}, with {{mono|/tmp}} being on a small root partition and {{mono|/{usr,var}/tmp}} being on a larger {{mono|/usr}} partition, {{mono|/var}} partition, or a partition of its own, so about all I'd say about {{mono|/tmp}}, tmpfs or no, is that it ''might'' be significantly limited in the total amount of available space, with no indication of whether that's the ''typical'' case or not (the machine on which I'm typing this has only one partition, a root partition, for all data, with both {{mono|/tmp}} and {{mono|/var/tmp}} on the root partition, and it runs [[OS X|a very common desktop UN*X]]). [[User:Guy Harris|Guy Harris]] ([[User talk:Guy Harris|talk]]) 18:45, 28 March 2015 (UTC)
:::::Stating that /tmp might be significantly limited in amount of available space looks good to me. Also I think many systems run for months without reboot so somehow it should also say that the files are expected to be cleaned regularly, not only on reboot. [[User:Richiez|Richiez]] ([[User talk:Richiez|talk]]) 11:57, 29 March 2015 (UTC)
::::::I wouldn't go so far as to say "expected", but I would say that old files might be removed without a reboot. [[User:Guy Harris|Guy Harris]] ([[User talk:Guy Harris|talk]]) 18:27, 29 March 2015 (UTC)
:::::::It is of course subject to configuration but users/software should expect that files in /tmp may be cleaned up regularly. Afaik 1-7 days based on atime are common? [[User:Richiez|Richiez]] ([[User talk:Richiez|talk]]) 11:32, 30 March 2015 (UTC)
::::::::Stating that tmpfs is a small filesystem with limited space is definitely a false claim as the limitation for tmpfs is sizeof RAM + sizeof swap and this typically is much more than /usr/tmp. I am disappinted to see that you repeatedly introduce this false claim. [[User:Schily|Schily]] ([[User talk:Schily|talk]]) 14:15, 30 March 2015 (UTC)
:::::::::Stating broadly, for all platforms, that tmpfs is, or isn't, a small file system with limited space is definitely a false claim, as:
:::::::::*on Linux, [https://www.kernel.org/doc/Documentation/filesystems/tmpfs.txt the documentation] says
tmpfs has three mount options for sizing:
size: The limit of allocated bytes for this tmpfs instance. The
default is half of your physical RAM without swap. If you
oversize your tmpfs instances the machine will deadlock
since the OOM handler will not be able to free that memory.
:::::::::*on Solaris, the size limit is based on the size of RAM ''plus swap'', and I can personally attest to sticking large files on tmpfs on Solaris.
:::::::::So it would be a mistake to say that {{mono|/tmp}} ''is'' a small file system or a file system that ''will'' be cleared or reboot or that ''will'' have files not recently referred to removed. We should, at most, note that it ''might be'' small (it is quite literally no smaller than {{mono|/var/tmp}} on my machine, as they're on the ''same partition'', and [[HFS+]] doesn't have per-directory size limits) and that files ''might be'' removed on reboot or ''might be'' removed after some period of time, depending on whether the OS you're using happens to use tmpfs or clean {{mono|/tmp}} on reboot (that's not a requirement, and, in fact, FreeBSD 10.1 didn't remove a file in {{mono|/tmp}} on reboot when I tried it just now) or whether {{mono|/tmp}} happens to be on a small root partition or whether it happens to be a tmpfs file system that imposes a RAM-only-based size limitation. [[User:Guy Harris|Guy Harris]] ([[User talk:Guy Harris|talk]]) 17:22, 30 March 2015 (UTC)
::::::::::Tmpfs on Solaris supports large files if the kernel is running in 64 bit mode. This is because a 32 bit kernel cannot deal with an address space > 4 GB (which still is larger than the official large file limit of 2**31-2 ;-) [[User:Schily|Schily]] ([[User talk:Schily|talk]]) 13:09, 31 March 2015 (UTC)
:::::::::the thing with filesystems, people know how big their hard drives are. Compared to that RAM+swap is usually ridiculously small, sometimes less then the memory of a mediocre phone and imho this is worth noting.[[User:Richiez|Richiez]] ([[User talk:Richiez|talk]]) 22:29, 30 March 2015 (UTC)
::::::::::"Compared to that RAM+swap is usually ridiculously small" "Usually" is different from "always". [[WP:NOTHOWTO|This isn't a howto]], so the purpose here isn't to give advice to personal workstation users as to how big their {{mono|/tmp}} directory is and how large a file they should expect to be able to put there, it's to give a picture that includes everything from a smartphone to a huge server.
::::::::::On a machine running Solaris 10, on which I have an account (it's not mine, so I don't know what it's physical configuration is), {{mono|/tmp}} has a 44GB {{mono|/tmp}} and a 161 GB {{mono|/var/tmp}}, so that's a factor of 3.65 difference in size. (As for phones, that's about halfway between, for example, the smallest [[Samsung Galaxy S6]] and the next storage size up and halfway between ''twice'' the smallest [[iPhone 6]] and the next storage size up.)
::::::::::({{mono|/tmp}} and {{mono|/var/tmp}} are, as noted, ''exactly the same size'' on my machine, which is running [[OS X|the UN*X that, as far as I know, has the largest desktop/notebook market share]]. It doesn't have tmpfs, however, and it has multiple temporary-file directories, including per-user ones, so using tmpfs in that context would be a bit of work; it also doesn't have a swap partition, it swaps to files in the file system, and adds new swap files as necessary and removes swap files when possible, so if there were an OS X tmpfs, it might well let you fill up the entire disk, just as you can with the regular {{mono|/tmp}} and {{mono|/var/tmp}} that default to both being on the root partition. It might still be faster, e.g. because it would only push tmpfs pages to the backing store if the VM system needed a free page, it wouldn't have to do so on a <code>sync()</code> or <code>fsync()</code> call, and thus might also be a bit gentler on SSDs.)
::::::::::So I'd be willing to have the article note that {{mono|/tmp}} ''might'' be limited in the amount of space available on it, but not willing to have it make a bold statement that it's only for "small" files, unless you'd consider, say, a 32 GB file, which would fit quite nicely on the tmpfs-based {{mono|/tmp}} on the Solaris box I referred to earlier, a "small" file. [[User:Guy Harris|Guy Harris]] ([[User talk:Guy Harris|talk]]) 23:23, 30 March 2015 (UTC)
:::::::: @ Schilly: I am wondering how much RAM your system has and if you designate most of your hard disk space to swap? Because on a typical workstation the RAM+swap is 100-1000x smaller than the available hard disk space. So on a typical workstation any tmpfs based system would be "small". Also, why are you talking about /usr/tmp all the time? It is not even mentioned in the article page as far as I can see. [[User:Richiez|Richiez]] ([[User talk:Richiez|talk]]) 22:22, 30 March 2015 (UTC)
::::::::: Is what matters the available hard disk space or the available space in temporary file directories?
::::::::: (And perhaps he's talking about {{mono|/usr/tmp}} because he, like me, used and developed on and for UN*X systems since before {{mono|/var}} even existed; I tend to speak of {{mono|/var/tmp}}, which the article most definitely ''does'' discuss, rather than {{mono|/usr/tmp}} now that all the UN*Xes out there have adopted the SunOS 4.x-derived directory layout with {{mono|/var}}, but perhaps Schily's a bit more old-fashioned than I am. :-)) [[User:Guy Harris|Guy Harris]] ([[User talk:Guy Harris|talk]]) 23:30, 30 March 2015 (UTC)
::::::::::I believe it was you whom I met in December 1987 in the ballroom of the Fairmount hotel in San Francisco at the Auspex booth on the SUG meeting...or was it December 1988 at the Fauntainebleau Hilton in Miamy Beach? I was working for H.Berthold AG at that time, the company that sold 1/4 of all Sun's made in the 1980s and we ordered the first Sun to Europe in January 1985.
::::::::::I believe that we are of comparable age (you might be a bit older). At that time, tmpfs has been invented by Sun and typical values for workstations at that time have been 4MB RAM, 20MB swap, 10MB root partition with aprox. 1MB free space, 60 MB /usr with aprox. 10 MB free space. So before using tmpfs, /tmp indeed was small compared to /usr/tmp (OK, /var/tmp was introduced with SunOS-3.x in 1986 to support diskless clients and to allow to mount /usr read only).
::::::::::With tmpfs, things changed dramatically, as there suddenly have been 20 MB free space in /tmp while there still only have been 10 MB in /var/tmp. As a result, the Sun C-compiler put tmp files to /tmp instead of /var/tmp and gcc frequently failed to compile larger projects because gcc stayed in the past and believed /var/tmp/ was still a good choice.
::::::::::11 years ago, I build my first Opteron based PC and there are 4 GB RAM, 10 GB swap, 10 GB root fs with 1 GB free space and /var/tmp is now on that space, so I have 10 GB of free space in /tmp and 1 GB of free space on /var/tmp. The ratio did not really change since 1988. But even on a newer server at my university, /var/tmp/ is not larger than /tmp. So the text introduced by [[User:Richiez]] is at least missleading and if we rate tmpfs, we should look at the original implementation instead of a Linux clone. [[User:Schily|Schily]] ([[User talk:Schily|talk]]) 12:07, 31 March 2015 (UTC)
== Add the /run directory ==
The run directory is a new addition to Linux that contains files that programs need through reboots, because /tmp is vulnerable to getting wiped. Is this a useful addition to the article? I'm asking this because this is article for the industry standard Unix filesystem, and not anything added by an OS. <!-- Template:Unsigned --><small class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:One Blue Hat|One Blue Hat]] ([[User talk:One Blue Hat#top|talk]] • [[Special:Contributions/One Blue Hat|contribs]]) 20:51, 16 January 2020 (UTC)</small> <!--Autosigned by SineBot-->
:{{u|One Blue Hat}}, I'd say probably not, because, as you said, this is based on the standard UNIX filesystem. [[User:Moonythedwarf|MoonyTheDwarf (Braden N.)]] ([[User talk:Moonythedwarf|talk]]) 20:55, 16 January 2020 (UTC)
::Yes - {{mono|/run}} is already covered in [[Filesystem Hierarchy Standard]], but not all Unix-like systems follow the FHS in its entirety. (macOS, for example, currently has {{mono|/var/run}} but not {{mono|/run}}.) [[User:Guy Harris|Guy Harris]] ([[User talk:Guy Harris|talk]]) 21:17, 16 January 2020 (UTC)
== Merge with [[Filesystem Hierarchy Standard]]? ==
The ''Conventional directory layout'' section contains information also in [[Filesystem Hierarchy Standard]]. Should the two be merged? <!-- Template:Unsigned IP --><small class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/151.53.72.73|151.53.72.73]] ([[User talk:151.53.72.73#top|talk]]) 23:22, 9 September 2020 (UTC)</small> <!--Autosigned by SineBot-->
:They both contain that information because the FHS is based on conventional UN*X usage, as per the quote from that section:
:{{quote|The details of the directory layout have varied over time. Although the file system layout is not part of the [[Single UNIX Specification]], several attempts exist to standardize (parts of) it, such as the [[UNIX System V|System V]] [[Application Binary Interface]], the [[Intel Binary Compatibility Standard]], the Common Operating System Environment, and [[Linux Foundation]]'s [[Filesystem Hierarchy Standard]] (FHS).}}
:I wish I could find a reference for this, but at least some of the layout comes from a proposal that some people at Sun made in the 1980's containing, among other things, the {{mono|/var}} directory; at least part of the goal was better support for [[diskless workstations]], with per-machine and shareable information divided up so that they could be on different remote-mounted file systems.
:Not every system that uses some form of the conventional layout follows the FHS. [[User:Guy Harris|Guy Harris]] ([[User talk:Guy Harris|talk]]) 00:23, 10 September 2020 (UTC)
| |||