xfs_fsr: XFS_IOC_SWAPEXT failed; & miscellania

[Linda A. Walsh]

Eric Sandeen wrote:
> Linda A. Walsh mumbled:
>> ...weird message...daily fsr run...root partition:
>>   meaning? file busy? 
>>
>> fsr[20906]: XFS_IOC_SWAPEXT failed: ino=16781994: Invalid argument
> 
> What kernel?  and what file is inode 16781994?  (find / -inum 16781994)
---
kernel name = "2.6.27.29-0.1-vanilla", from distro SuSE 11.1
	(It's the unpatched version of their current kernel.)


> EINVAL can come from many places; trying to defrag a swapfile is one of 
> them ...
---
	inode corresponds to '/etc/samba/secrets.tdb'
miscellanea 

It would appear samba doesn't like its "secrets" file possibly being
'defraged' ;^) moved around.  Hmmm...

Would that be because of a "file lock" or would just being 
"open" cause that?  Maybe Memory mapped?

Odd that I haven't seen it on other days... (i.e. it's not a message
I normally see, which is why I asked about it...).

-l

------
p.s. - other thoughts(related to using xfs_io/bmap)...

BTW...just in using xfs_io/xfs_bmap a bit and the man pages,
some comments.  Don't know which are under your control and
which are due to distro-config defaults, or which
are due to my specific configuration (or lack thereof), but:

doc related:
1) when not using "hyperlinked manpages" that invoke program output,
(;-)), things like being able to see 'referenced' flag names that
are displayed in a program (like for xfs_io{lsattr|chattr}') isn't
easy.
It might be nice, if possible, to include the 'current set' of [supported]
options in the man page.  The situation of a reader viewing the 
'remote information' (the actual options displayed in the active
program) could be worse -- they could be in a browser and have no
access to a console window.  Of course in that case, if the manpages
were being displayed from a machine that had the command, a properly
configured webserver would have a plugin to run the command and 
show the output in a scrolled <pre> region, in real time....:-).

&doc related+FYI
2) reading the xfs_io manpage, it referred to the xfsctl manpage 
o find out params for some sub-command.  Some (unnamed, but one might 
have a hint by my kernel usage) "bright" distro packagers have the
idea that even 'manpages' about library or system functions are
'development' material that goes in a separate (not included by default)
'devel' rpm.  (sigh).  Don't know if there's any automated
way to include info from that manpage in the relevant sections, to prevent
the information from being separated, but something to think about
if the documentation ever gets re-arranged (not soon, I'm sure, but
just an FYI).


Question:
3) I'd been using chattr to change options like "+d" (nodump) on xfs
options. It seems to work.  Is that accidental or by design?  Maybe there
needs to be a 'chattr.xfs' subcommand and chattr needs to call a 'flavor'
based on filesystem...(I know that's partially an 'upstream' issue).


Enhancement?
4) is it possible to configure the xfs_utils with 'readline' and history
support?  -- allowing re-edit of previous lines and even a restoration
of one's previous command history on entry?

At least the readline support would be helpful  given my typing accuracy
(i.e. re-edit of previous line...though even a history that only lasts
for the given session, could be useful for repeating commands on multiple
files...