|
Home > Archive > Data Storage > August 2004 > Question on External RAID Disaster Scenario
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Question on External RAID Disaster Scenario
|
|
| Ernest Siu 2004-08-27, 5:46 pm |
| The question is on the role of host cache during disaster with SAN.
Let's assume a simple setup with a host connecting to an external RAID
box. An application write data, host put them on it's page cache and
tells the application that it's done, and so application carries on.
While the dirty data are still sitting in the host cache, the power on
the external RAID died (or cable cut).
Questions:
- is the above description correct - host page cache is for both read
and write-back?
- does this implies the application has lost/corrupted user data
because it thought it has completed the write?
- will the host timeout the write? is the timeout parameter
configurable? is it the OS or the filesystem?
- what about the directory structure (inode and other metadata stuff)?
are they always on write-through mode? what if it is not?
filesystem corruption?
Regards,
Ernest
| |
| Bill Todd 2004-08-27, 5:46 pm |
|
"Ernest Siu" <ernestsiu@yahoo.com> wrote in message
news:2833144d.0408270916.23df61c1@posting.google.com...
> The question is on the role of host cache during disaster with SAN.
It's not clear that the presence or absence of a SAN makes any difference in
this scenario.
> Let's assume a simple setup with a host connecting to an external RAID
> box. An application write data, host put them on it's page cache and
> tells the application that it's done, and so application carries on.
> While the dirty data are still sitting in the host cache, the power on
> the external RAID died (or cable cut).
>
> Questions:
> - is the above description correct - host page cache is for both read
> and write-back?
Yes, usually.
> - does this implies the application has lost/corrupted user data
> because it thought it has completed the write?
No: in typical environments no application has no right to assume that it
has 'completed' a write (i.e., that the data is persistent) unless it either
specifies write-through behavior on the write operation or 'flushes'
('syncs') the data explicitly.
> - will the host timeout the write? is the timeout parameter
> configurable? is it the OS or the filesystem?
Usually; usually; the file system.
> - what about the directory structure (inode and other metadata stuff)?
> are they always on write-through mode?
Depends upon the file system, and/or on the options selected in it.
what if it is not?
> filesystem corruption?
Not necessarily: The 'soft updates' version of the file system on *BSD
systems should prevent any corruption even with write-back handling of
metadata (but of course can still 'lose' the last few updates on a crash).
- bill
| |
| Lianghwa Jou 2004-08-28, 8:45 pm |
| Bill Todd wrote:
> "Ernest Siu" <ernestsiu@yahoo.com> wrote in message
> news:2833144d.0408270916.23df61c1@posting.google.com...
>
>
>
> It's not clear that the presence or absence of a SAN makes any difference in
> this scenario.
>
>
>
>
> Yes, usually.
>
>
>
>
> No: in typical environments no application has no right to assume that it
> has 'completed' a write (i.e., that the data is persistent) unless it either
> specifies write-through behavior on the write operation or 'flushes'
> ('syncs') the data explicitly.
>
If an application really want to have control, it should use the raw
device to bypass the filesystem. Orcale DBMS usually does that.
>
>
>
> Usually; usually; the file system.
>
>
>
>
> Depends upon the file system, and/or on the options selected in it.
>
> what if it is not?
>
>
>
> Not necessarily: The 'soft updates' version of the file system on *BSD
> systems should prevent any corruption even with write-back handling of
> metadata (but of course can still 'lose' the last few updates on a crash).
>
> - bill
>
>
>
| |
| Bill Todd 2004-08-28, 8:45 pm |
|
"Lianghwa Jou" <ljou1@comcast.net> wrote in message
news:41312065.1070404@comcast.net...
....
> If an application really want to have control, it should use the raw
> device to bypass the filesystem. Orcale DBMS usually does that.
Actually, Oracle has increasingly been happy to layer on top of file systems
like VxFS, which provide flexible and, if desired, direct access to disk
without sacrificing the conveniences of a logical rather than a physical
interface.
The bottom line is to use a file system that gives you the degree of control
you desire while masking the complexity that can still be masked. And
different file systems vary considerably in this regard.
- bill
|
|
|
|
|