Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Alex-
Leader Leader
Leader

Appliance root partition

I wonder if there's still a reason to cap root partition at 32G on appliances, when open servers can be adjusted during installation.

For instance, I've been installing a large VSX environment with high-end appliances fitted with reasonable SSD drives and with a mix of blades the root partition is already almost full while /var/log will barely be used.

 

Consider this:

Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/vg_splat-lv_current   32G   31G  1.8G  95% /
/dev/md0                         291M   62M  214M  23% /boot
tmpfs                             47G  141M   47G   1% /dev/shm
/dev/mapper/vg_splat-lv_log      292G   21G  272G   7% /var/log
cgroup                            47G     0   47G   0% /sys/fs/cgroup

 

I had a discussion with PS folks who told me that some blades share components or online updates so they're sort of active even if not all blades are active on all VS and in the case of VSX some of these components are duplicated by design on each VS which can lead to that kind of situation. But I've also seen non-VSX installations nearing full capacity when all blades are active over time, and I'm speaking of latest OS versions and hotfix.

 

3 Replies
Oliver_Fink
Advisor
Advisor

That is a question I asked myself many times in the past. On a VSX cluster of one customer we see:

  • / = 32 G, free 8.2 G
  • /var/log = 150 G, free 79 G
  • Snapshots = > 600 G (Snapshot size < 28 G)

I have no need for > 20 snapshots, but more than 8 G on / sometimes would be helpful. There is space enough for 50 G, 64 G or even 100 G for /.

0 Kudos
andreicrb
Explorer

Hello,

I have the same problem but on a virtual security gateway, the root partition keeps getting full and there is nothing that I could delete in order to make some more space and I don't think this is the correct way of solving this problem. Right now it's at 97% utilization, yesterday was at 82%.

[Expert@HOSTNAME:0]# df -kh
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_splat-lv_current 30G 25G 5.7G 82% /
/dev/sda1 290M 60M 215M 22% /boot
tmpfs 7.8G 18M 7.7G 1% /dev/shm
/dev/mapper/vg_splat-lv_log 60G 43G 18G 72% /var/log

[Expert@HOSTNAME:0]# df -kh
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_splat-lv_current 30G 29G 1.1G 97% /
/dev/sda1 290M 60M 215M 22% /boot
tmpfs 7.8G 18M 7.7G 1% /dev/shm
/dev/mapper/vg_splat-lv_log 60G 44G 17G 72% /var/log

What is there to be done to address this?

Thank you!

0 Kudos
PNH
Participant

Hello, I have also run into this problem a lot on larger installations (VSX and/or with many in-place upgrades)

It is time they put up larger root partition on appliances by default

For VSX, before R81.20, each VS that has IPS and AMW etc will download the updates into its own context (even if they of course are exactly the same files for all of them)

It is possible to move the directory trees for the update over to /var/log partition, see sk176665.

Be sure to copypasta the script properly (did I say backup first also maybe??)

I have done this on several R81.10 systems without problems while they were up and running

 

In other ways, since root partition is part of linux lvm it can be expanded, but it may later maybe break upgrades, I have not tested.

 

 

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events