Appending more storage space to the file system

wblock@ said:
Excellent! As far as I know, only drives 1T or larger use 4K blocks, meaning partitions on the smaller drive do not need any special alignment.
Click to expand...

The "WD 750GB WD7500BPVT" claims to have "Advanced Format-Technologie", according to my local box-pusher. I think that was the 4k per sector format, so it may also appear in smaller disks.
 
wblock@ said:
To be aligned, the data partition must start at an even multiple of 4K. Drives usually pretend to have 512-byte partitions even when they are really 4K. The primary GPT table takes 34 512-byte blocks. The next aligned spot is at block 40. I suggest starting the first data partition at 1M, or block 2048, for compatibility with other operating systems.
Click to expand...
Code: 
4 K = 8 512-byte blocks

40 / 8 = 5
Five is not even so 40 is not an even multiple of 4 K I guess.

Please could you explain?

P.S. How does gpart(8)'s [-a alignment] option work?
 
Not even, even multiple:

40 * 512 = 20480
20480 / 4096 = 5, an integer (no fraction)

So block 40 (20480 bytes) is an even multiple of 4096, or 4K.

All that the -a option in gpart(8) does is round the partition starting location and size up to the nearest multiple of the value given.
 
wblock@ said:
Not even, even multiple:

40 * 512 = 20480
20480 / 4096 = 5, an integer (no fraction)

So block 40 (20480 bytes) is an even multiple of 4096, or 4K.

All that the -a option in gpart(8) does is round the partition starting location and size up to the nearest multiple of the value given.
Click to expand...

Thanks. It was my bad interpretation, sorry.

I have repartitioned the disk and restored a backup. I got a message like this during restore(8):
Code: 
./.sujournal: (inode 4) not found on tape
Should I worry about this?

It seems like the system is working just fine after restoring. However, df(1) shows that there is -776M of available space. That's weird taking into account that the new partition is bigger than the previous one. Is there any way to reclaim missing disk space?

Thanks.
 
pietrasm said:
I have repartitioned the disk and restored a backup. I got a message like this during restore(8):
Code: 
./.sujournal: (inode 4) not found on tape
Should I worry about this?
Click to expand...

No, that file will be recreated.

It seems like system is working just fine after restoring. However, df(1) shows that there is -776M of available space. That's weird taking into account that the new partition is bigger than the previous one. Is there any way to reclaim missing disk space?
Click to expand...

That sounds wrong, but it's hard to guess what is happening. du -k -d1 in various directories can be used to track down what is taking space.
 
wblock@ said:
That sounds wrong, but it's hard to guess what is happening. du -k -d1 in various directories can be used to track down what is taking space.
Click to expand...

The drive was almost full before the operation and it's slightly overloaded now. The difference in volume is not significant, so it will be hard to track it down. However, I will take a closer look.

Thanks.
 
A file called restoresymtable is left in the root directory of each filesystem. Deleting those will save a little space.
 
wblock@ said:
A file called restoresymtable is left in the root directory of each filesystem. Deleting those will save a little space.
Click to expand...

Thanks, I have noticed this file just after restoring the root partition but it's only about 60 MB long.

I took a closer look on this. I have tried to restore(8) the backup into another directory and it has exactly the same volume as on the root partition. I guess that dump(8) backup file isn't broken.

I think the issue is caused by increased file system overhead for some reason. I have changed minimum disk space required to 7% and toggled optimization for space using tunefs(8)'s -m and -o switches respectively. Then I have restored the root partition once again and I have almost 2 GB of available space now. I think it's about the same as before repartitioning.

Unfortunately, I don't remember UFS configuration of the original file system and there is now way to check it. I have created it using bsdinstall(8)'s automatic 'Entire Disk' option when I was installing FreeBSD 9.0. It's rather weird that bsdinstall(8) left almost a GB of free disk space at the end. Moreover, a smaller partition had greater effective capacity. Maybe, bsdinstall(8) doesn't use newfs(8)'s defaults?

Thanks for help.
 
bsdinstall(8) may use a higher number of inodes, there were problems with running out of them on earlier versions. And partition size may have been rounded down to the nearest full gigabyte.
 
wblock@ said:
bsdinstall(8) may use a higher number of inodes, there were problems with running out of them on earlier versions. And partition size may have been rounded down to the nearest full gigabyte.
Click to expand...

Do I need to increase the number of inodes when using newfs(8) or the default is fine now?

Thanks.
 
Spread over a single big filesystem, it's probably okay. You didn't run out when doing the restore, for instance. If you did run out, it would just be a matter of backup, newfs(1) with a higher number of inodes, and then a restore.
 
wblock@ said:
Spread over a single big filesystem, it's probably okay. You didn't run out when doing the restore, for instance. If you did run out, it would just be a matter of backup, newfs(1) with a higher number of inodes, and then a restore.
Click to expand...

Thanks.

I try to dump(8) a /usr/home directory. It's located on the root partition, it's not a separate file system. I got following error:
Code: 
root@mfsbsd:/mnt2 # dump -C16 -b64 -0aL -h0 -f - /mnt/usr/home | restore -ruf -
dump: /mnt/usr/home: unknown file system
Tape is not a dump tape
root@mfsbsd:/mnt2 #
I guess the problem is that /mnt/usr/home is not a separate file system. Is there any way to make dump(8) to dump only a subdirectory of a file system? What's the best way to move /mnt/usr/home to a new partition?

Thanks.
 
Right, dump(8) only deals with full filesystems.

cp(1) can be used to recursively copy directories, but net/rsync is better at it. (There's also sysutils/clone). For rsync(1), build the port with the FLAGS option enabled and use these options to make an exact duplicate of of the source directory in the dest directory:
rsync -axHAXS --delete --fileflags --force-change source/ dest/

The trailing slashes on the source and dest directories are important.
 
wblock@ said:
Right, dump(8) only deals with full filesystems.

cp(1) can be used to recursively copy directories, but net/rsync is better at it. (There's also sysutils/clone). For rsync(1), build the port with the FLAGS option enabled and use these options to make an exact duplicate of of the source directory in the dest directory:
rsync -axHAXS --delete --fileflags --force-change source/ dest/

The trailing slashes on the source and dest directories are important.
Click to expand...

I have used sysutils/clone as it seems to be less complicated. It's a new piece of software but it seems to work correctly. I have tested the server for a last few days and everything looks good.

Thank you all for help. Special thanks to @wblock@.
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top