[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Linux-cluster] error messages while use fsck.gfs2


On Wed, Nov 16, 2011 at 7:55 PM, Steven Whitehouse <swhiteho redhat com> wrote:
> Hi,
> On Wed, 2011-11-16 at 19:44 +0530, Rajagopal Swaminathan wrote:
>> Greetings,
>> On Wed, Nov 16, 2011 at 7:13 PM, Bob Peterson <rpeterso redhat com> wrote:
> I'm not quite sure which feature you are suggesting that we take, but
> I'd be surprised that if the start of a ZFS filesystem were to be
> overwritten that it could be easily reconstructed.

Well, Self correction/healing like some kinda block level CRC check?

Cores are cheap nowadays.

I do understand that I/O is still expensive at the OS level.

I would anyday prefer a MD raid to h/w raid as the disk can be simply
ported to another system and the RAID lives.

I know I am being a bit (or a lot) vague here.

> The problem here is "how much is enough?". If we kept the first 8 blocks
> of the fs duplicated, then someone would come along and overwrite the
> first 16 and them say why did you choose only 8? We could duplicate
> everything, but then why not simply mirror at the block device level?

Now, I _did_ opine on the matter of the sysadmin managing a cluster
who does not monitor any command/process which does low level access
to disk.

I can't comment on some RDBMS preferring "Raw devices".

> Which is not to say that we couldn't usefully learn a few lessons from
> what other filesystems are doing, but only that I'm not sure that it
> would help for this particular issue.

IMHO, It is quite simple: have multiple backups of critical data at
every level -- be it block level, filesystem, files etc. etc., if not
pragmatic in local, then a remote system.

I have implemented at least a few RHCS way back in 2007-2009. Some,
who could afford, were using storage (like IBM DS<something>,
Sun<somemodel>, HP<somemodel>) and, many, DRBD.

Apologies if I sounded arrogant, It is just the pain I have
encountered when it comes to cost.

Well, again, above just my IMHO.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]