Originally Posted by
sussexlad
I'm just left then with the question, how do you make a external SSD mountable on a LVM setup ?
External storage can use or not use LVM. It is up to you. For data-only, not an OS, there are reasons for both of those options. Or you could decide to use ZFS or one of the 20+ other solutions. Storage on Linux has lots and lots of options, depending on the need.
But ... the simple answer is don't use LVM for just data storage unless you need snapshot support.
To do that, do it like any other disk.
- Create a partition table on the whole disk, use GPT. gparted, fdisk, parted can all do this.
- Create at least 1 partition. gparted, fdisk, parted can all do this.
- If you use gparted, format the partition with ext4 as the file system.
- Give the file system a LABEL. again, gparted makes this easy.
- Don't forget to "Apply" your gparted changes.
That's all the prep work.
Now for the mounting. There are a number of methods:
- sudo mount command from a terminal
- modify the /etc/fstab
- use autofs to mount the storage on-demand and umount it when it isn't used.
The easy answer is to setup the fstab, but then the storage has to be there at boot and cannot be removed. I don't do that for USB or networked storage, since those connections can be flaky and disappear.
Because you gave the file system a LABEL during the prep-work above, you can easily mount the storage using that unique LABEL in the fstab. Add a line like this:
Code:
LABEL={whatever-label-you used} /media/{whatever-label-you used} ext4 nofail,noatime,errors=remount-ro 0 2
Use sudoedit /etc/fstab to safely edit the fstab. Add that line. The label you choose cannot have any spaces in the name.
When done, run this command to force systemd to re-scan the fstab and the mount -a to mount all storage that is inside the fstab.
Code:
sudo systemctl daemon-reload
sudo mount -a
That should be it.
gparted rocks. There are other tools, but they aren't nearly as capable. You may need to install gparted .... or not. It is worth having installed. I don't trust the gnome-disks app.
If you want to use LVM, do all the prep-steps up to the point of formatting a file system. Then you'll want to follow an LVM guide. For an SSD, I'd recommend a few things to get flexibility and to drastically increase the SSD lifetime.
Leave 20% of the total storage un-partitioned. This allows the SSD to have more storage space for wear leveling.
Inside the partition, setup 1 VG, but only allocate the LV storage as needed for 1-3 months growth. Increasing LV sizes is trivial and easy while the file system is online. Decreasing an LV is an off-line operation and can require backup+wipe first. If you use LVM, then you'll likely want to also use LVM snapshots for backups. These are dynamic - create/delete - just during backups, so you'll likely want to limit the total allocated VG storage to 80-90% of the total available so 10-20% is available for those snapshot LVs.
After you create the PV, VG, and any LVs you need, then you use mkfs to format the LV as desired with the filesystem you want. If you don't use ext4, then all sorts of LVM+ext4 features are not available. LVM and EXT4 are designed to be used together.
So see the different commands for vg, lv, and pv stuff, use tab completion:
pv{tab}{tab}
vg{tab}{tab}
lv{tab}{tab}
Basically, each command work like this:
create, convert, reduce or extend and finally remove.
Code:
$ pv{tab}{tab}
pvchange pvcreate pvmove pvresize pvscan
pvck pvdisplay pvremove pvs
$ vg{tab}{tab}
vgcfgbackup vgconvert vgextend vgmknodes vgs
vgcfgrestore vgcreate vgimport vgreduce vgscan
vgchange vgdisplay vgimportclone vgremove vgsplit
vgck vgexport vgmerge vgrename
and the same for LVs.
sudo pvs, vgs, lvs are the overview commands for each LVM object type. The vgdisplay, lvdisplay, and pvdisplay commands aren't really needed anymore, unless you really need to see all the details. I haven't in years, but the detail are there if you like to look.
LVs are treated just like partitions. They get file systems (mkfs on LVs is blazing fast compared to normal partitions). They get mounted. They get fsck'd.
The manpages for each of these commands is really great, but you'll want a clear understanding of how each of the objects fit together. LVM does add some complexity, but that usually only matters about 5 minutes every 5-10 yrs. The rest of the time, will be spent being happy you used LVM and knowing that 5-10 seconds with an lvextend command can add storage where you need it, when you need it. No guessing 4 yrs ago which I promise you'll get wrong. I've been doing storage for 25+ yrs and have yet to guess correctly where I needed storage.
Heck, on a fresh 20.04 install in June, I got the storage guess wrong. My desktop install had been using 25G total storage for about a decade, but after the 20.04 install where I gave it 30G, I found it was always running out of storage. LVM to the rescue.
Code:
$ sudo pvs
PV VG Fmt Attr PSize PFree
/dev/vda5 vgubuntu-mate lvm2 a-- <29.50g 0
/dev/vdb1 vgubuntu-mate lvm2 a-- <10.00g 6.39g
$ sudo vgs
VG #PV #LV #SN Attr VSize VFree
vgubuntu-mate 2 3 0 wz--n- 39.49g 6.39g
$ sudo lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
home vgubuntu-mate -wi-ao---- 12.00g
root vgubuntu-mate -wi-ao---- 17.00g
swap_1 vgubuntu-mate -wi-ao---- 4.10g
$ df -hT
Filesystem Type Size Used Avail Use% Mounted on
/dev/mapper/vgubuntu--mate-root ext4 17G 10G 5.9G 63% /
/dev/mapper/vgubuntu--mate-home ext4 12G 6.2G 5.0G 56% /home
/dev/vda1 vfat 511M 7.1M 504M 2% /boot/efi
Can you see what I did? BTW, the system was active, booted, running, the entire time these changes were made.
Bookmarks