(re: timelag: It took me a few revisions to get this out..)
Dave Chinner wrote:
Can you please ensure that you are running an up-to-date xfsprogs
and not some mix-and-match of different versions with differing
feature support capabilities?
----
Will the latest version allow me to specify
finobt=1, ftype=1 && projid32bit=0 with crc=1?
I'm pretty sure I don't have a version of xfs_admin that
disallows setting the GUID in the presence of a mkfs.xfs that does.
As to how they would get mismatched, I have "/" on a different
partition from "/usr" (among others). My distro has been moving files
from "/" -> /usr primarily the bin & lib dirs. xfs_admin in their
setup was in /usr/sbin/ before this "move", while mkfs.xfs was in /sbin
(along with xfs_repair and fsck.xfs). They have been "supporting the
old paths by moving the binaries under /usr, while putting symlinks
from progs like "/bin/mount" -> "/usr/bin/mount". On systems like mine,
that would result in system that boots but can't mount any other file
systems. So wrote script that detected "mount order", and dereferenced
unsafe symlinks that pointed to file systems later in the mount order.
Since the xfsprogs were split, and I hadn't gotten around to
inspecting date-stamps on binaries (I *did* manage to do version checks
on libraries, as mount's libraries were moved to /usr/lib64 before
mount was -- so the /bin/mount wouldn't load w/o /usr mounted.
There's also the fact that I've tried to keep the mkfs & xfsrestore
utils on the rootfs -- since that's allowed me to recover/restore
/usr and /var partitions that have gone belly up, but backups and such
aren't that important to most people, it seems.
Also, needless to say, suse couldn't move from /usr to "/", because
"/" is now on device /dev/rootfs, so programs and users won't easily know
when they are running in a "container" or "virtualized" root. Anyway,
this move has caused a few headaches and not just to me.
As for the 'crc' option:
I wouldn't mind having the 'crc option being a default'
just as 'recovery' and 'uuid' are default -- I.e. allow mounting
a crc-fs w/o crc checks -- so a known bad disk can still have data
recovered from it. It seems the ability to make a file system with
crc=0 while other options (finobt ftype) can be on would be a
pre-rerequisite for allowing that at *mount* time (in addition to
mkfs time).
I use norecovery, to mount 'temporary' snapshots as I
know, the logs may be out-of-sync with the contents, but for
my purposes that's never been a problem.
Since it seems that 'ftype' is headed toward crc-independence,
and finobt (I think) is hoped to be more efficient for free space
allocation, -- just how much metadata is normally associated with
free space (i.e. normally I think of time/date/access/ext_attrs
as metadata)?
I keep trying to keep my xfs-repair and restore utils
on my rootfs (whether it has /usr on it or not), since, more than
once I've been able to restore a /usr or /var from the rootfs alone.
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
