So, Roger.<br><br>Suppose you have only a single partition / and want to mount it read-only...how are you going to accommodate this ?  Hm?  I&#39;d imagine you have a terrific time since all inodes reference back to /.  This will include all sub-mount below /...<br>
<br>The purpose of multiple partition/mount is for flexibility.<br><br>You are free to choose a partition scheme as you see fit.<br><br>PCBSD used to have / only during install.  People complained about that too!<br><br>Best,<br>
Quyen<br><br><div class="gmail_quote">On Fri, Sep 24, 2010 at 2:18 PM, Roger Marquis <span dir="ltr">&lt;<a href="mailto:marquis@roble.com">marquis@roble.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Kris Moore wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I&#39;m inclined to agree with Andrei here. The standard way to do<br>
auto-partitioning is what we&#39;ve been doing, with /, /var, /usr, and<br>
swap.<br>
</blockquote>
<br>
This was the standard back when it was required by the imitations of<br>
single disks were not large enough to accommodate an entire distribution,<br>
but has not been standard, if by standard you mean used by a majority of<br>
Unix and Linux installations, since.<br>
<br>
Legacy or not I would hope that the goal of any partitioning scheme would<br>
be to accommodate the largest number of users.  Partitioning /usr, without<br>
an explicit rational, clearly does not meet that test.  That /usr is<br>
still partitioned in PC-BSD indicates that the current scheme is<br>
legacy-based as opposed to use-based.<br>
<br>
Partitioning /var is nearly as bad in my experience, for the reasons<br>
outlined previously.<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
&quot;/&quot; and &quot;/var&quot; only take up around 2-6GB of space, leaving the<br>
rest for your main operations in /usr. That seems like a pretty<br>
reasonable amount to reserve for critical areas of the system.<br>
</blockquote>
<br>
But then you often have to create partitions for /tmp and /var/tmp, and<br>
symlink them, and reduce log archiving, or archive to another partition.<br>
Dump, cdrecord, and rsync among others often need more than a few GB on<br>
/tmp or /var/tmp for one common use-case.<br>
<br>
I think what we should be looking at are use-cases.  When someone pays me<br>
to reinstall a server that became problematic due to a small root, or<br>
var, or usr partition, or is experiencing performance issues due to root<br>
mounts, that indicates a serious problem.  Cases where a single root<br>
partition creates diskfull issues are far less common, by one or two<br>
orders of magnitude.<br>
<br>
Question is what problems would have been avoided by partitioning /var on<br>
the same disk?  Not in theory but in practice.<br>
<br>
Roger<br>
_______________________________________________<br>
Dev mailing list<br>
<a href="mailto:Dev@lists.pcbsd.org" target="_blank">Dev@lists.pcbsd.org</a><br>
<a href="http://lists.pcbsd.org/mailman/listinfo/dev" target="_blank">http://lists.pcbsd.org/mailman/listinfo/dev</a><br>
</blockquote></div><br><div style="visibility: hidden; display: inline;" id="avg_ls_inline_popup"></div><style type="text/css">#avg_ls_inline_popup {  position:absolute;  z-index:9999;  padding: 0px 0px;  margin-left: 0px;  margin-top: 0px;  width: 240px;  overflow: hidden;  word-wrap: break-word;  color: black;  font-size: 10px;  text-align: left;  line-height: 13px;}</style>