LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Frantisek Rysanek" <Frantisek.Rysanek@post.cz>
To: linux-kernel@vger.kernel.org
Subject: Re: block layer / FS question: x86_32bit with LBD, 20 TB RAID volume => funny issues
Date: Fri, 07 Mar 2008 07:10:35 +0100	[thread overview]
Message-ID: <47D0EA6B.18428.A235AEC4@Frantisek.Rysanek.post.cz> (raw)
In-Reply-To: <75b66ecd0803061905n5c06663cv2b75659917461199@mail.gmail.com>

On 7 Mar 2008 at 4:05, Lee Revell wrote:
> >  I didn't even try Ext3, I know it's not appropriate for this sort of
> >  capacity.
> 
> Where did you get that idea?
>
Hmm... Google can find sources on the 'net claiming that Ext3 has a 
maximum of 2 or 4 TB. Nice to know that I'm wrong, I'll test this 
right away :-)
 
> Are you sure the hardware is not faulty?
>
I'm pretty sure. 
I know what it looks like when one of those 1TB drives has a problem 
it would prefer not to talk about in SMART (hint: only one disk 
activity LED out of 24 keeps blinking). Nowadays I have to handle 
several such drives in every new RAID unit delivered. 
When such a drive times out past some margin, say half a minute, the 
Linux kernel reports a SCSI CMD timeout, or rather, the RAID 
controller runs out of patience sooner than the kernel, the array 
gets degraded and keeps going on in degraded mode. So if the RAID 
controller itself goes out for lunch, Linux definitely complains. 
I've also seen a number of sly SCSI parity errors / general bus 
impedance problems, all of which yielded a proper error within half a 
minute or so. I am well equipped to debug such problems. Besides, 
this is FC. 
Once upon a time I've seen some ugly low-level incompatibility in FC 
too - that resulted in some really nice messages from the Linux 
kernel. 
I also know a brand of controllers which claim support for TCQ depth 
of 255, but actually hang with anything over 192 or so. This also 
yields a proper error in Linux, and the RAID controller goes toes up. 

None of this happens in my case... all is happy and calm.
Hmm... maybe I should try some modern FreeBSD for comparison :-)))

Apologies for not mentioning specific hardware brands - I don't want 
to get in trouble...

> > Would it be any help if I switched to 64bit mode?
> 
> Yes, it would be worth a try.
> 
:-/ Okay, time to install 64bit Fedora 8 or something :-)

Anyway, thanks very much for your response :-)

Frank Rysanek


  parent reply	other threads:[~2008-03-07  6:10 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-06 21:25 Frantisek Rysanek
     [not found] ` <75b66ecd0803061905n5c06663cv2b75659917461199@mail.gmail.com>
2008-03-07  6:10   ` Frantisek Rysanek [this message]
2008-03-07  9:30     ` Andi Kleen
2008-03-07 10:48       ` Frantisek Rysanek
2008-03-09  4:26     ` Lee Revell
2008-03-09 22:05 ` David Chinner
2008-03-10  4:32   ` Frantisek Rysanek
2008-03-10  9:13 Frantisek Rysanek
2008-03-13 10:14 Frantisek Rysanek

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=47D0EA6B.18428.A235AEC4@Frantisek.Rysanek.post.cz \
    --to=frantisek.rysanek@post.cz \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: block layer / FS question: x86_32bit with LBD, 20 TB RAID volume => funny issues' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).