Re: expand UFS partition

On 11/16/23 10:52, Jim Pazarena wrote:
> I have a UFS which is near full, and I know there is spare/un-allocated 
> space on the hard drive.
> I can not back it up first , as it is both huge and very busy.

	It is always easier to schedule downtime than it is to schedule data 
loss. Not sure what definition of 'huge' and 'very busy' is, but if it 
is important data, it'd be worth negotiating improving it to 
hardware/use plan that permits backups actually happen unless the data 
isn't important. Otherwise, you may want to look into adding dump(8) as 
a background task that the system has to perform if the data is 
important; though system backups are always best when the system is 
'offline' to do it, most data is valuable even when copied on a live 
system and dump supports both.

> Are there any tools within FreeBSD to (a) examine if expanding this UFS 
> is possible, and (b) expand it reliably ?

	If there is usable space just after the UFS partition then:
man 8 growfs
	I have no experience with it. I haven't followed bug reports/upgrades 
around it closely to know if it and UFS of your FreeBSD vs v12+ have any 
fixes you could benefit from, performance improvements, or if it could 
make any changes you would need to undo; may be worth looking into if 
you 'rebooted' for the task. I'd presume growing the filesystem doesn't 
take long (but don't know it as a fact) and gpart partition editing 
definitely doesn't as its just a table about where partitions are and 
doesn't interpret their contents itself. I thought there was some 
technical downside to growing a UFS partition vs having it originally 
formatted to the size but do not recall it at the moment.
	My resizing partitions experience came from the Windows world. It 
always consisted of 1. scan disk+filesystem for errors, 2. rework 
partitions from separately booted media, 3. rescan filesystem for 
errors. I never proceeded past 1 if errors were found until resolved and 
I never had long term issues as long as #3 was also performed.

> I have gparted, and could run it. Which would involve bringing down the 
> server for that duration.
> All fine & dandy... but can I trust gparted to not wreck this task ?

	I haven't had issues with gpart other than user error and only once 
with gvinum when I used it for a parity disk array and a drive died 
which lead to it swapping the other drives around for some unknown 
reason; fixed it with dd and a text editor that time. Overall I've only 
had minor interactions with them. If the gparted you talk of is 
represented here https://gparted.org/features.php , then no, it will not 
wreck, nor perform, the task of resizing the partition. It could help 
you shuffle partitions around if free space is not at the end but moving 
and copying are all that software does for UFS; you may need to edit 
fstab entries if partition count before the desired partition changes 
which that tool also will not likely do. I'd expect moving partitions to 
take time if it is a partition type it doesn't fully understand how to 
manipulate (UFS); the larger the partition then the more data to read+write.

> A back up first would take the server down for several hours. I cannot 
> take it down for that long.
> Now, if I wreck the drive, hind-set would have kicked me square in the 
> butt.
> 
> I suppose that I could test the reliability of this task on a spare 
> server. And likely will.
> Unless, that is, FreeBSD has a built in ability.
> 
> Also... old FBSD .. 11.0 p1 ! ouch

	Maybe negotiate resolving that once backups have been resolved; Overall 
I'm happier with changes that require newer versions but it depends on 
your use. I 'think' my system has been smoother about me putting heavy 
load tasks in the background while continuing to use it as updates come 
along.

> Thanks !
>