public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Stan Hoeppner <stan@hardwarefreak.com>
To: xfs@oss.sgi.com
Subject: Re: mounting hixfs (Hitachi "tuned" XFS) on 2.6 kernel
Date: Tue, 18 May 2010 18:34:52 -0500	[thread overview]
Message-ID: <4BF3241C.5080001@hardwarefreak.com> (raw)
In-Reply-To: <AANLkTim93-4YueMBizXKLGRFka2vwqzJzDx5_P5gs0bl@mail.gmail.com>

big beer put forth on 5/18/2010 10:19 AM:

> It's called a eNAS, but it's really just 2 linux 2.4 blades (debian
> woody), with failsafe (think heartbeat), LVM, custom XFS, samba, nfs,
> and a pile of sudo available scripts that are 700 and a web based gui
> to manage it.
> 
> I though about moving it via another FS on the NAS and then connecting
> it to my target migration host also. The only exposed connections on
> the hardware are ethernet, and it's integrated in the storage
> subsystem. I'd have to call a tech  to even come take it out. So I'm
> limited to something that is fiber attached to the sub-system, ok
> that's fine, just means no USB disk or the like. The real problem is
> that since I don't have root there is no way to create or mount any
> other devices that contain another FS. The restrictive GUI/scripts
> automatically creates and mounts FS's with their modified XFS version,
> and there are no options to do otherwise.
> 
> I'm playing it "safe" by taking a block level copy of the luns that
> are exposed to this thing, and then presenting the copy over to my
> target host. I'm not brave enough to totally trash live data. I'm
> going to give some of the suggestions a go with a fresh copy of the
> data and see what comes of it.

Ahh, ok.  We're not talking about some cheap single box NAS appliance here
with 4-10 local disks, but a blade "appliance" which connects via FC to SAN
LUNs on back end arrays.  And lemme guess, the sales guy pitched
"flexibility" as a main selling point.  A poor rich man's NetApp so to
speak.  Sounds like a decent setup.  Except for the fact that protocols
change, along with Samba features.  It is flexible, except in the way you
currently need it to be.

Agreed, you're not taking chances.  I didn't comprehend previously what
exactly you were doing.  Thanks for the explanation.  Snapshotting the LUNs
is obviously a very safe method.

> Of course the 1st thing I did was call Hitachi support and ask them
> what the deal is, dropping words like "GPL" and "license bound to
> distribute", but to no avail. Of course I'm dealing with low level
> support people that more than likely didn't work for the big H when
> this thing was built. I've escalated through the channels I have
> available to me.

Well, they've done what they can to lock you into their NAS solution...

Is the actual blade hardware that terribly slow?  If not, do they offer a
new "firmware" load for that blade bringing it up to a Hitachi proprietary
2.6.x kernel with a much newer Samba/NFS/etc?  I know you'd rather whip up a
solution yourself with standard FOSS stuff, but maybe this would be a viable
option for now if they offer it.  Given the blade's age they probably don't
offer anything to upgrade it.  Can't hurt to ask.

> We'll see what comes of it.

Any chance you can build a system from an old Woody installation set that
closely matches what's on the NAS?  Then copy over their hacked proprietary
HIXFS modules, mount the HIXFS LUNs and copy everything to an EXT2 formatted
LUN?  If you can get this far you're home free.  I guess the hard part will
be getting access to those modules and libraries since you can't login as
root...

-- 
Stan


_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  parent reply	other threads:[~2010-05-18 23:29 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-18  0:08 mounting hixfs (Hitachi "tuned" XFS) on 2.6 kernel big beer
2010-05-18  1:24 ` Stan Hoeppner
2010-05-18  3:34   ` big beer
2010-05-18  4:21     ` Dave Chinner
2010-05-18  4:23     ` Eric Sandeen
2010-05-18  4:37     ` Stan Hoeppner
2010-05-18 15:19       ` big beer
2010-05-18 16:44         ` Benjamin Lau
2010-05-18 16:57           ` Roger Willcocks
2010-05-18 22:43             ` big beer
2010-05-19  4:19               ` Stan Hoeppner
2010-05-19 13:53                 ` Eric Sandeen
2010-05-19 14:03                   ` Stan Hoeppner
2010-05-18 23:34         ` Stan Hoeppner [this message]
2010-05-18  3:47 ` Eric Sandeen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BF3241C.5080001@hardwarefreak.com \
    --to=stan@hardwarefreak.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox