>On Mon, May 17, 2010 at 6:24 PM, Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx> wrote:
> big beer put forth on 5/17/2010 7:08 PM:
>> If anyone has any ideas on what to do, and/or where to start, I'd
>> greatly appreciate it.
> Why are you avoiding the obvious solution in favor of hacking?
> xfs mailing list
Sending back to the list this time instead of Stan directly (Sorry Stan) :)
The obvious solution for me would be a backup or rsync. Unfortunately
both of those have issues with this particular setup.
Using a backup over the network to migrate will be way too slow
(days). There are way too many files to index and this poor little nas
box is already falling over with cpu load from daily activities. I can
quickly make a mirror on the storage, and move it over to another
larger host quickly (minutes). Mounting the FS on another machine will
greatly improve the time and accuracy, as I won't have to worry about
inconsistencies as it's a block level copy.
The black-box solution is also very painful to work with, no gcc, no
automake, no rsync, etc.
I would also think that for some reason I can't think of, it would be
nice to have support for this version of XFS be available for free for
others. Some other poor sap might find some value.
So I went and changed the magic number to 0x58465342 by dumping the
1st 512 bytes off the volume, editing, and writing back, now I'm
getting "Can't verify primary superblock". Using xfs_db to look at the
other superblocks indeed still shows HXFS. Any advise how I can
find/dump/re-write one of the other superblocks? I'd like to see if I
can change another one of them if xfs_repair will run.