Re: Problem: How to resize FreeBSD "partitions" on a live system?

Begin <1150422511.937242.238610@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
On 2006-06-16, KimmoA <kimmoa@xxxxxxxxx> wrote:
[context missing]
It seems that your preferred suggestion is actually to make a symlink
to a /usr location. While I can see that it could work, doesn't that
take away the entire point of dividing the system from the beginning?

No, not at all. I agree that it can easily convolute the system into
incomprehensibility, but letting that happen, or not, is up to you.
Think carefully about what both really do. If you do you should be
able to work out the details of the answer.


Also, isn't it bad practice to change the default location?

Defaults themselves are best left alone. If you don't feel comfortable
changing settings from their defaults, then by all means, leave them
as they are. But if you have a need to change them, then you have the
possibility. And that certainly is much better than needing to and not
having the possibility.

It is good practice to justify your actions with reason and to document
the whole setup so that forgetting how you'd done it is less of a risk.


I am myself still more than a little confused over "Unix" directory
structure to begin with, but it seems that they have been thought
through and have a very good reason for being that way. Or am I wrong?

Compare, for example, the FreeBSD ports collection and the NetBSD take
on the same idea, pkgsrc: The former installs in /usr/local by default,
whereas the latter religiously uses /usr/pkgsrc, leaving /usr/local for
*local* additions.

There is usually at least some reason why layouts are the way they are,
but what the reason is or was, exactly, differs greatly and may even be
lost in time. ``Unix'' is, after all, 30+ years old already.

The main point is that you do have the tools to be extremely flexible
about what you do with your disk space including way down the road.
Whether what you do with that is wise is in the eye of the beholder.
You can ask for advice, but there is no single right answer, hence my
referral to the archive of this group for more discussion.


Yes, I am a perfectionist. I can't stand unclean systems and can
actually lose sleep over that kind of thing, even if everything works
perfectly fine and nobody will ever know about it (but me, that is).

Writing site documentation with concise records of the what and where
it differs from the defaults and why, can perhaps alleviate that loss
of sleep. With proper host documentation, even if you do something
``unclean'', which you inevitably will simply because you have not
worked out how to do it properly yet, you or others won't lose as much
time over finding out how it all was setup N months down the road.


In the past, when I have asked something similar, I have basically got
replies such as "that's why you can easily change it later" (referring
to re-arranging space for the partitions). It doesn't seem to be that
easy at all...

Not if you believe it has to be done through re-partitioning. But if
you have unallocated space (set aside earlier, adding another disk,
etc.), you can allocate it, put a filesystem on it, and drop it in
the tree wherever necessairy. Even if you have to move some data to
the new mountpoint, you don't have to take full backups, redo all the
filesystems, and restore from backups.


In Windows, I remember using some commercial third-party GUI tool
("Partition Magic"?) that could easily re-arrange them.

But do note that, as you say, it is a *third party* offering. Windows
itself offers no provisions like unix does, at all. Even its take on
symlinks is shaky and only works half the time. Not to mention that
micros~1 filesystem technology is... lagging behind the competition[1],
and has for years. From the start, even, as Bill points out.


I must admit that I expected there to be some kind of program bundeled
with FreeBSD that could change the "slices" freely, only requiring a
reboot to take action... Apparently, that is not the case.

But do note that the tools you have (*working* softlinks, freedom
to mount in more space almost wherever you want, fairly centralised
configuration, various bundled backup/restore tools, not to mention
vinum and --if you like to live dangerously-- growfs) do give you a
tremendous amount of flexibility already. Just not bundled in a gui.


Hmm... I'm leaning towards letting everything be at / + swap, because I
take backups only of my own files, reinstalling the system in case of
an emergency... It's the philosophy and performance parts that worry
me...

Then you haven't paid attention. I did mention, as did others, that
dump/restore works best on a filesystem basis, and that is just one
reason why you'd want to separate the system and your own data.


[1] To people who now point out that NTFS is ``OK'', or whatever, I can
only say: Maybe in theory, I've never seen it work well in practice,
certainly not without third party tools. Especially recovering from
booting-preventing errors leaves much to be desired.

--
j p d (at) d s b (dot) t u d e l f t (dot) n l .
This message was originally posted on Usenet in plain text.
Any other representation, additions, or changes do not have my
consent and may be a violation of international copyright law.
.

Relevant Pages

  • Re: HDD Crashed- Trying to figure out what IP/Hostname was
    ... Yes I know DHCP is better, but I have no choice at ... OK - but what's the reason they so desperately need to know this in the ... If they have no documentation, no full backups, no DHCP ...
    (microsoft.public.windowsxp.network_web)
  • Re: Very Large Filesystems
    ... snaps can be trusted? ... Who said don't make backups? ... How much better off are a million files on a single filesystem ... Backing-up a corrupt file doesn't fix it. ...
    (comp.arch.storage)
  • Re: Very Large Filesystems
    ... Who said don't make backups? ... How much better off are a million files on a single filesystem ... Backing-up a corrupt file doesn't fix it. ... I have never seen NTFS ...
    (comp.arch.storage)
  • Re: [SLE] Apache2 - and suse 9.2 yast stupidity
    ... > Well i cant see the reason why the apache config went ... make backups of system and other config files before you make any ... least I don't blame the distro for my own idiocy. ...
    (SuSE)
  • Re: [RFC][PATCH] ensure i_ino uniqueness in filesystems without permanent inode numbers (via idr)
    ... There is virtually no reason that a filesystem would ... ever need to touch these structures in another filesystem. ... functionality in question is easier to reimplement, ... I can't imagine that this attitude will affect support from software ...
    (Linux-Kernel)