[Suggestion] Override mkfs opts decided by fsarchiver

I haven't checked this myself so I could be deeply wrong here, but I reviewed the source code at https://github.com/fdupoux/fsarchiver/blob/master/src/fs_xfs.c and it looks like, at least for XFS, that I won't be able to restore the filesystem and at the same time, upgrade the XFS fs flags. I understand why this is done: to have 100% guarantee that the restored filesystem will behave as it was at the moment of restoration.

But at least myself, I'd like to upgrade the XFS filesystem from time to time and for that using a backup from fsarchiver would be ideal since it's my tool of choice for this purpose since it's quite good.

As you now, there are flags that can only be set up at the moment of filesystem creation. If in the past I didn't create my XFS fileystem without a specific flag, fsarchiver will enforce it to not have that flag at the moment of backup restoration, for example, like with rmapbt xfs flag.

From what I saw with the mkfsopt option from command line (restfs op), that will just append to whatever flags are decided by fsarchiver at the end (

fsarchiver/src/fs_xfs.c

Line 277 in c20ecd2

strlcatf(mkfsopts, sizeof(mkfsopts), " %s ", fsoptions);

), so if fsarchiver indicates "-m rmapbt=0" and I say to fsarchiver mkfsopt=-m rmapbt=1, then mkfs.xfs will just fail because both values cannot be done at the same time (mkfs.xfs just doesn't take the last repeated value as the canonical one for the operation and assumes user failure to provide a clear command - this I tested it myself fallocating a big file and trying to create an XFS filesystem inside it with both values at the same time).

So my proposal is to have an option to enable a middle step where the enduser can see the mkfs.xfs-with-arguments line that it's going to be executed by fsarchiver before it happens and have the option to edit it before continuing forward. Any other proposal would be acceptable like having a way to override those mkfsopts from command line (i.e. fsarchiver detects that the user wants to change a flag from the backup and modifies the value without appending mkfsopt from command line as-is).

An alternative for me, I don't know if it's possible, it's to tamper with fsarchiver metadata in the backup to change the value of those flags, but I haven't investigated that much :D

Thank you!

This would require a new command line option. The question is: does it worth the effort for such corner case? I do not think so.

You can drop temporarily in /usr/local/sbin a shell script called mkfs.xfs with:

#!/bin/bash

exec /usr/sbin/mkfs.xfs -foo bar ${@:$#}

And put your options there.

Thank you for the workaround. I didn't think of that. It will require a bit of trial & error I guess and since it's something that I'll only do once per many years, it's ok with me to do it that way.

But let me show you that this is not really a corner case. It's actually recommended in Arch Linux wiki to avoid using filesystem backup tools to precisely do what I'm suggesting (tip at the top): https://wiki.archlinux.org/title/Disk_cloning

Tip: Over time file systems get new features and the mkfs utilities change their defaults, but not all new features can be enabled without reformatting. So, when moving data to a new drive, instead of cloning the block devices or file systems, consider creating a new file system and only copy the files (and their attributes, ACLs, extended attributes, etc.) with e.g. rsync.

If fsarchiver becomes that flexible, it will become even more useful and it won't be recommended to people to craft a backup script with rsync or tar to do such operation.

In case this is considered for a future fsarchiver version, of course, such options should be flagged as expert / experimental mode. It won't be a fault of the tool when, for example, someone disables a flag that prevents a specific extended attribute to be created in each file and then obviously filesystem restoration will be incomplete or failed.

But anyway, this issue with your trick will be here to whoever wants to update the filesystem with fsarchiver, so having at least that option although hacky is ok.