xfs
[Top] [All Lists]

Re: mounting hixfs (Hitachi "tuned" XFS) on 2.6 kernel

To: xfs@xxxxxxxxxxx
Subject: Re: mounting hixfs (Hitachi "tuned" XFS) on 2.6 kernel
From: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
Date: Mon, 17 May 2010 23:37:58 -0500
In-reply-to: <AANLkTin_WoxWP3JXHvflVVP_2fGzgbSVfpPW1KGiyd1z@xxxxxxxxxxxxxx>
References: <AANLkTikek9K8-BqNgee_tXz72beHpWEUl41YtDPrD-3P@xxxxxxxxxxxxxx> <4BF1EC44.7070803@xxxxxxxxxxxxxxxxx> <AANLkTin_WoxWP3JXHvflVVP_2fGzgbSVfpPW1KGiyd1z@xxxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
big beer put forth on 5/17/2010 10:34 PM:
>> 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?
>>
> Sending back to the list this time instead of Stan directly (Sorry Stan) :)

No problem.  I love my Tbird "reply-to-list" option. :)

> 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.

Seems to me you're taking some big chances with live data.  One wrong turn
and you could hose the FS and lose all the data, yes?  I'd rather give you
recommendations not related to this current path you're taking.  Would you
please provide the model or part number of this Hitachi NAS so I can get an
idea of what exactly it is you're dealing with, and possibly offer other
solutions?

Maybe someone else here can help you pull this off via XFS.  I can't.  But
I'll gladly spend some time researching other possible solutions, mainly
getting a high capacity drive connected so you can do a cp -a or tar and be
done with this overnight, in a data-safe manner.

-- 
Stan

<Prev in Thread] Current Thread [Next in Thread>