stratis filesystem showing as xfs and mounted as xfs in fstab but is it really xfs ??

[dmcquay]

Hey all,

Not really finding an answer when Googling for this so I'm going to ask here. I noticed that in the advanced storage chapter review stratis filesystem is showing xfs when running blkid and we are mounting the filesystem in /etc/fstab as xfs but is it really an xfs filesystem? At no point do the reviews have you actually format the filesystem as xfs. When looking at the stratis-storage.github.io page it says that it works with a number of storage technologies like; device-mapper, LUKS, XFS, and Clevis.

Thanks,

DM

[Trevor · Accepted solution]

Hello DM,

The answer to your question is: Indeed XFS is the
filesystem that resides on the block device that is used
in the pool that is created.

At the end of my reply, I'll show you 4 diferent
commands that you can use to verify this:

1) lsblk 
2) blkid
3) file
4) xfs_info

First, let's setup a disk block device to play with. 
I'm using an EC2 instance, in the AWS cloud, running
RHEL 8.6.  I only mention this because of what my 
device filename for my block device will look like:

            /dev/xvdf

I'm assuming that startis is already installed,
started, and ready to go!   Also, in the commands
that I show, I will not be including any output, as
that will cause this post to be a little lengthy.
Okay, let's begin.

First, let's create a pool:

#  stratis  pool  create  s_pool  /dev/xvdf

-  s_pool is the name of the pool that I'm creating

If you want to verify that the pool was created:

#  stratis  pool  list

Now, i want to create a filesystem on the pool 
that I created earlier.

#  stratis  filesystem  create  s_pool  trevor

-  Again, s_pool is the name of the pool that
     I created earlier
-  trevor is the name of the filesystem that
     is being created.  Okay, the name "trevor"
     is not a name that would be used for a 
     filesystem in the practical world, but I like
     attention.  Be sure to understand "trevor" is the
     name that I'm associating with the filesystem,
     and it is NOT the filesystem TYPE!!!   "trevor"
     is NOT the filesystem TYPE!!!

You can now verify that the filesystem has been
created using the following command:

#  stratis  filesystem  list

-  Among other things in the output, you
    see the pool name (s_pool), the filesystem
    name (trevor), etc.  However, you do NOT
    see the filesystem TYPE!!!

So, at this point, I have a device with an 
XFS filesystem on it.  Note:  I'm stating things
this way because I want to keep the explanation
simple, and not get into the intracies of some 
of the things that are going on behind the scenes
regarding the device itself (physical vs virtual).  

Right now, if I wanted to mount what I just created,
the pathname to that item would be as follows:

        /dev/stratis/s_pool/trevor

Again, to keep things simple, I'm going to ask
that you look at the name "trevor" as a device
filename.

If you've performed these steps on a system
of your own, you're now in position to verify the
answer to your question: Is it live, or is it memorex
(is the filesystem really/actually XFS).

Proof 1:

# lsblk  -f  /dev/stratis/s_pool/trevor

Proof 2:

# blkid  -p  /dev/stratis/s_pool/trevor

Proof 3:

# file  -sL   /dev/stratis/s_pool/trevor

Proof 4:

# xfs_info  /dev/stratis/s_pool/trevor

In the output of each of the 4 commands,
therein lies your proof that the filesystem
type is really, actually, XFS!!!

Still not convinced?  Try that last command,
xfs_info on a ext4 formatted filesystem, then
take 2 aspirin, and call me in the morning.

Thanks for the question!

[dmcquay]

Hi Trevor and dnaspliceoflife,

Thanks for your detailed responses and for clearing this up for me. I did some testing in the lab environment and, as you both pointed out, putting anything other than xfs as fs type fails to mount the drive.

Trevor, I was not aware of the xfs_info nor did I think to try running file on it but that makes sense. I happened to stumble upon this when I ran blkid on the device and saw it listed as xfs so that's when my curiousity came from. 

Anyhow, thanks again for both of your responses they were very helpful in clearing this up for me. 

Best,

DM

[dnaspliceoflife · Accepted solution]

To build on Trevor's discussion on filesystem verification strategies, another element to the stratis puzzle is thinking about where does that filesystem live. Yes, it is living in the stratis pool but in a way that is slightly different from ways that you may have thought about storage in the past.

I'm going to lean into the pool metaphor a little here. Think of the stratis pool as an actual swimming pool. In that pool there can be one or more inflatable pool toys. These are your filesystems. The toys can be uninflated, partially inflated or fully inflated (as an analogy for a file system getting closer to it's maximal permitted size). As you add more files to the file system the pool toy gets closer to being fully inflated and takes up more space. If 2 toys are next to one another, inflating one may bump up against another and the exact location of the pool toy in the pool may shift and move.

Stratis, essentially, does the grunt work in the background to make sure the file systems have their own space in the pool. The user just sees the filesystem.

It's real benefit comes from understanding how it builds on logical volume management. The stratis pool is similar to a volume group.  In that volume group you can create several logical volumes, each with their own files system but that all have predefined, set space allocations and defined start and end points in that volume group. They are easy to adjust in size but it is a manual process. (I have to go in and issue the commands to expand the lv, extend the filesystem to fit this new space etc.). Stratis does this automatically and is invisible to the end user.

So, to sum up, Stratis is a way to define a storage pool and in that pool many different filesystems can exist. Stratis does the backend management of dynamically allocating space for filesystems and the end user simply mounts any filesystem that exists in that pool at a location of his/her choice