Relocating VXFS intent log(Journal)?

[cuddles@salmahayeksknockers.edu]

My environment is experiencing problems with intermittent SAN failures.
While we are working to resolve them, we're also considering ways to cushion
the impact of such failures.

One of the ideas considered is moving the VXFS intent logs off of the SAN FSes,
to local disk, in the hopes it will be less vulnerable to spontanous LUN
disappearance

Is there validity to this idea? Can it be done? Any speculations as to the
degree of performance hit this would create?

TIV,
Dan.

--
.................................................. ............................

Beauty comes cheap in a wealthy country

.................................................. ............................
[email]dswan@m3m3t1ccand1ru.com[/email] [url]http://www.memeticcandiru.com[/url]

[Darren Dunham]

[email]cuddles@salmahayeksknockers.edu[/email] wrote:

> My environment is experiencing problems with intermittent SAN failures.
> While we are working to resolve them, we're also considering ways to cushion
> the impact of such failures.

What are you expecting here? Just to avoid damage, or to pause until
the SAN returns?

> One of the ideas considered is moving the VXFS intent logs off of the
> SAN FSes, to local disk, in the hopes it will be less vulnerable to
> spontanous LUN disappearance

About the only thing I'd recommend is to make sure you have at least
VxFS 3.4 with the latest patches. That allows you to mount with the
option 'ioerror=disable'. The first error in writing data or metadata
will cause the filesystem to go offline. This generally means that
after you recover the SAN, the filesystem can be restarted with few or
no errors. That's a lot better than having it attempt to continue,
trashing portions of the system.

> Is there validity to this idea? Can it be done? Any speculations as to the
> degree of performance hit this would create?

If you're trying to keep the system "up but paused" until the disks
return, I'd only attempt to do that at the fiber driver level where it
retries below the level of the OS for some time before returning a hard
error. I don't see much benefit to moving the intent log around.

--
Darren Dunham [email]ddunham@taos.com[/email]
Unix System Administrator Taos - The SysAdmin Company
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >

[l1nux_L3w1s@salmahayeksknockers.edu]

Darren Dunham <ddunham@redwood.taos.com> wrote:

> What are you expecting here? Just to avoid damage, or to pause until
> the SAN returns?

Hoping to protect the Journal from corruption.

> About the only thing I'd recommend is to make sure you have at least
> VxFS 3.4 with the latest patches. That allows you to mount with the
> option 'ioerror=disable'. The first error in writing data or metadata
> will cause the filesystem to go offline. This generally means that
> after you recover the SAN, the filesystem can be restarted with few or
> no errors. That's a lot better than having it attempt to continue,
> trashing portions of the system.

Good suggestion... I will put it in my hopper. I think this is a different
way of doing what I want.

> If you're trying to keep the system "up but paused" until the disks
> return, I'd only attempt to do that at the fiber driver level where it
> retries below the level of the OS for some time before returning a hard
> error. I don't see much benefit to moving the intent log around.

Thank you very much.


--
.................................................. ............................

There are only two mistakes one can make along the road to truth:

One, not going all the way; and two, not starting.

-Buddha (Siddhartha Gotoma)

.................................................. ............................
[email]dswan@m3m3t1ccand1ru.com[/email] [url]http://www.memeticcandiru.com[/url]