[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: solution to / full



Hello,

On Wed, Mar 01, 2023 at 07:53:19PM +0100, Nicolas George wrote:
> Andy Smith (12023-03-01):
> > > /dev/nvme0n1p2   23G   21G  966M  96% /
> > > /dev/nvme0n1p6  267M   83M  166M  34% /boot
> > > /dev/nvme0n1p1  511M  5.8M  506M   2% /boot/efi
> > > /dev/nvme0n1p3  9.1G  3.2G  5.5G  37% /var
> > > /dev/nvme0n1p5  1.8G   14M  1.7G   1% /tmp
> > > /dev/nvme0n1p7  630G  116G  482G  20% /home
> > This is an excellent illustration of why creating tons of partitions
> > like it's 1999 can leave you in a difficult spot.
> 
> No it is not. The /boot and /tmp partitions are superfluous, and
> /boot/efi is too large (but at a guess it was already there), but they
> would barely make a difference.

I was talking about them going to the effort of separating /home and
/var and ending up with completely inappropriate sizings. They would
have been much better off just not bothering and having it all in /.
The mere presence of all these other partitions laid out on this
disk after the one for / makes resizing things a lot harder than it
needs to be.

> On the other hand, in 2023, it is still a very good idea to separate the
> system filesystem that gets written frequently from the one that gets
> written rarely from the user data filesystem.

No argument there, but not with disk partitions as they end up hard
to resize, as seen here. OP is quite fortunate that their last
partition is one that can be most easily shrunk as that at least
gives them some easier options. I'd agree it would be a better
example of a tight spot if their last partition were one they
couldn't shrink!

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Attachment: signature.asc
Description: PGP signature


Reply to: