Now, of course, we need to dive out to our command line.
We already have our ext4 filesystem, so we won't need to add that to our
partition, but we can then go through and start reading some of our metadata
about the filesystem and configuring the volume label.
So, of course, we're going to treat you to a trip to Alma Linux 8 where we
already have our ext4 filesystem on the encrypted device.
We need to open the encrypted device, a cryptsetup and luksOpen.
And don't forget during the opening, we have to specify the device that we
want to open and the dev mapper name that we want to use.
So we're opening loop1p1 and opening it to my‑data. Enter our passphrase.
Hopefully, you can remember it. And once, then that's entered, we're
able to access our filesystem, which we've already accessed on that
device, but we want to start reading some of the metadata. To get
the most metadata, we can use the dumpe2fs command and point through
now to our device.
But remember, it's going to be the dev mapper device that we use. Now we
do get a lot of information here, including the superblock information
from our filesystem. So we might prefer to look for information that
we're particularly interested in.
So we saw in the slides, I can do a case insensitive search for mount,
space, count. And we'll see, we haven't mounted this so far.
Our maximum mount count is set to ‑1,
which means that we're not going to implement a filesystem check
based on the times that this has been mounted.
There is also a check interval that we should check. On modern
ext4 filesystems, both of these are usually disabled, and it's
important that they are. A filesystem check, then can be
automated when you least want it.
You reboot a machine,
you expect it to take 10 minutes to reboot, and you find out it takes 10
hours because a filesystem check had to be carried out.
We can run our filesystem checks when we want out of hours, and
it's not going to affect our business process.
So do check it on your ext4 filesystems. But if we're only interested in,
instead of our superblock information, just the properties of the
filesystem, then we might be better off using tune2fs.
So if we go through and use this with the ‑l for list, all of our device, again,
the same dev mapper device,
we're going to be able to see the keys and values set in our filesystem.
As we scroll back up to the top, one of the first things that we're going
to notice is the filesystem volume name.
We commonly call this the label.
It's not been set at the moment, but we can use that both to document our
filesystem, but also use it to mount our filesystem.
The last mounted on can be really useful. Especially where you've had a
major disaster, you've now pulled out a whole load of disks from a
server, perhaps that has failed, but we don't know which disk is which.
By checking where it was last mounted,
we're probably going to get a good idea as to the purpose of this disk.
As we scroll down, we can see further keys. Looking a little bit
further down the screen, we can see, again, our maximum mount count,
so that's not implemented. The last check date, well that's when we
created the filesystem, but the check interval on 0, then there is no
regular interval of days,
weeks or months that we need to do a filesystem check, as I don't
really want to do one in any automated manner,
be it the maximum mount count or the interval between checks.
We can schedule this to happen every 3, 4 months, whatever
we want, but schedule it to happen in your diary to carry
out the tasks out of hours.
If we want to set the disk label,
the disk label then helps document our filesystem, but we can
also use this in mounting our filesystem.
We can use the option ‑l. If we go through now and
just read the top of this data,
we can see now that we have the volume name set. But say there are
other properties that can be really useful in documenting, and we're
going to take a look at the last mounted on.
So if I go through and create a mount point directory, so if I
just run mkdir, and for simplicity, we'll just say /data, if we
then go through and clear our screen,
we can go through and use the mount command. We can mount,
as I say, by the label, so label = my‑data, and we'll mount it into the
data directory. With this now mounted, again, I'm going to clear my
screen, but we can write some information through to our filesystem, so
I'm just going to echo hello through to data and then file1 or whatever
we want to call it.
It's important that we do write to the filesystem, and this will then ensure
once we've unmounted it, we will have our last mounted on. To rerun the tune
command, we can go through and use the exclamation mark and tu, the last
command that started with tu, and you can see there we see the top 10 lines,
and that includes the last mounted on. So we can see how important this
metadata is relating to our disks.
So even in the event of a disaster, at least we know the volume name and where it was last mounted to.