On Thu, Sep 13, 2012 at 4:45 PM, Stan Hoeppner <stan@hardwarefreak.com> wrote:
> On 9/13/2012 5:20 AM, Veljko wrote:
>> On Tue, Sep 11, 2012 at 08:34:51AM -0500, Stan Hoeppner wrote:
>>> One of the big reasons (other than cost) that I mentioned this card is
>>> that Adaptec tends to be more forgiving with non RAID specific
>>> (ERC/TLER) drives, and lists your Seagate 3TB drives as compatible. LSI
>>> and other controllers will not work with these drives due to lack of
>>> RAID specific ERC/TLER.
>>
>> Those are really valuable informations. I wasn't aware that not all
>> drives works with RAID cards.
>
> Consumer hard drives will not work with most RAID cards. As a general
> rule, RAID cards require enterprise SATA drives or SAS drives.

They don't work with real hardware RAID? How weird! Why is that?


Thanks,
Kelly Clowers


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/CAFoWM=8780zJNkk2DiWZ2UuvT-G7L+dVkn3LD43Fckm-A+e0NA@mail.gmail.com

On 20120910_053746, Stan Hoeppner wrote:
> On 9/9/2012 3:25 PM, Paul E Condon wrote:
>
> > I've been following this thread from its beginning. My initial reading
> > of OP's post was to marvel at the thought that so many things/tasks
> > could be done with a single box in a single geek's cubicle.
>
> One consumer quad core AMD Linux box of today can do a whole lot more
> than what has been mentioned.
>
> > I resolved
> > to follow the thread that would surely follow closely. I think you,
> > Stan, did OP an enormous service with your list of questions to be
> > answered.
>
> I try to prevent other from shooting themselves in the foot when I see
> the loaded gun in their hand.
>
> > This thread drifted onto the topic of XFS. I first learned of the
> > existence of XFS from earlier post by you, and I have ever since been
> > curious about it. But I am retired, and live at home in an environment
> > where there is very little opportunity to make use of its features.
>
> You might be surprised. The AG design and xfs_fsr make it useful for
> home users.
>
> > Perhaps you could take OP's original specification as a user wish list
> > and sketch a design that would fulfill the wishlist and list how XFS
> > would change or resolve issues that were/are troubling him.
>
> The OP's issues don't revolve around filesystem choice, but basic system
> administration concepts.
>
> > In particular, the typical answers to questions about backup on this list
> > involve rsync, or packages that depend on rsync, and on having a file
> > system that uses inodes and supports hard links.
>
> rsync works with any filesystem, but some work better with rsync
> workloads. If one has concurrent rsync jobs running XFS is usually best.

Rsync features that invoke hard links are commonly used to do
de-duplication in backup systems that are designed with extX file
system in mind. Other parts of rsync work without hardlinks in the
file system. But, I think a common desire of people seeking advice
here is that there be some sort of automatic, easy to administer,
de-duplication.

>
> > How would an XFS design
> > handle "de-duplication"?
>
> Deduplication isn't an appropriate function of a filesystem.

The wording of this question was too terse. I should have said
something like:

How would a backup system design that uses XFS implement
de-duplication?

I know that file-systems don't do de-duplication, but the rsysc
program does do de-duplication in the case of extX file system. What
alternative method for achieving de-duplication might be substituted
for rsync?

>
> > Or is de-duplication simply a bad idea in very
> > large systems?
>
> That's simply a bad, very overly broad question.

Yes, but de-duplication is a feature that it highly touted as a "good
thing". Is there some easy way to have de-duplication *and* the
benefits of XFS in a single, optimized design of a backup system?


--
Paul E Condon
pecondon@mesanetworks.net


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120914181327.GB3164@big.lan.gnu">http://lists.debian.org/20120914181327.GB3164@big.lan.gnu

On 9/14/2012 7:57 AM, Martin Steigerwald wrote:
> Am Freitag, 14. September 2012 schrieb Stan Hoeppner:
>> Thus my advice to you is:
>>
>> Do not use LVM. Directly format the RAID10 device using the mkfs.xfs
>> defaults. mkfs.xfs will read the md configuration and automatically
>> align the filesystem to the stripe width.
>
> Just for completeness:
>
> It is possible to manually align XFS via mkfs.xfs / mount options. But
> then thats an extra step thats unnecessary when creating XFS directly on
> MD.

And not optimal for XFS beginners. But the main reason for avoiding LVM
is that LVM creates a "slice and dice" mentality among its users, and
many become too liberal with the carving knife, ending up with a
filesystem made of sometimes a dozen LVM slivers. Then XFS performance
suffers due to the resulting inode/extent/free space layout.

Of course, this is fine when a user knows the impact up front and can
live with a 10+ fold decrease in performance when the FS starts filling
up. Once this gets bad enough the only fix is to dump, format, restore
the filesystem. And that gets expensive when we're talking many TB.

--
Stan


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 5053A530.5000608@hardwarefreak.com">http://lists.debian.org/5053A530.5000608@hardwarefreak.com

On 9/14/2012 11:29 AM, Kelly Clowers wrote:
> On Thu, Sep 13, 2012 at 4:45 PM, Stan Hoeppner <stan@hardwarefreak.com> wrote:
>> On 9/13/2012 5:20 AM, Veljko wrote:
>>> On Tue, Sep 11, 2012 at 08:34:51AM -0500, Stan Hoeppner wrote:
>>>> One of the big reasons (other than cost) that I mentioned this card is
>>>> that Adaptec tends to be more forgiving with non RAID specific
>>>> (ERC/TLER) drives, and lists your Seagate 3TB drives as compatible. LSI
>>>> and other controllers will not work with these drives due to lack of
>>>> RAID specific ERC/TLER.
>>>
>>> Those are really valuable informations. I wasn't aware that not all
>>> drives works with RAID cards.
>>
>> Consumer hard drives will not work with most RAID cards. As a general
>> rule, RAID cards require enterprise SATA drives or SAS drives.
>
> They don't work with real hardware RAID? How weird! Why is that?

Surely you're pulling my leg Kelly, and already know the answer.

If not, the answer is the ERC/TLER timeout period. Nearly all hardware
RAID controllers expect a drive to respond to a command within 10
seconds or less. If the drive must perform error recovery on a sector
or group of sectors it must do so within this time limit. If the drive
takes longer than this period the controller will flag it as bad and
kick it out of the array. The assumption here is that a drive taking
that long to respond has a problem and should be replaced.

Most consumer drives have no such timeout limit. They will churn
forever attempting to recover an unreadable sector. Thus routine errors
on consumer drives often get them kicked instantly when used on read
RAID controllers.

--
Stan


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 5053A6C6.8060606@hardwarefreak.com">http://lists.debian.org/5053A6C6.8060606@hardwarefreak.com

On Fri, Sep 14, 2012 at 2:51 PM, Stan Hoeppner <stan@hardwarefreak.com> wrote:
> On 9/14/2012 11:29 AM, Kelly Clowers wrote:
>> On Thu, Sep 13, 2012 at 4:45 PM, Stan Hoeppner <stan@hardwarefreak.com> wrote:
>>> On 9/13/2012 5:20 AM, Veljko wrote:
>>>> On Tue, Sep 11, 2012 at 08:34:51AM -0500, Stan Hoeppner wrote:
>>>>> One of the big reasons (other than cost) that I mentioned this card is
>>>>> that Adaptec tends to be more forgiving with non RAID specific
>>>>> (ERC/TLER) drives, and lists your Seagate 3TB drives as compatible. LSI
>>>>> and other controllers will not work with these drives due to lack of
>>>>> RAID specific ERC/TLER.
>>>>
>>>> Those are really valuable informations. I wasn't aware that not all
>>>> drives works with RAID cards.
>>>
>>> Consumer hard drives will not work with most RAID cards. As a general
>>> rule, RAID cards require enterprise SATA drives or SAS drives.
>>
>> They don't work with real hardware RAID? How weird! Why is that?
>
> Surely you're pulling my leg Kelly, and already know the answer.
>
> If not, the answer is the ERC/TLER timeout period. Nearly all hardware
> RAID controllers expect a drive to respond to a command within 10
> seconds or less. If the drive must perform error recovery on a sector
> or group of sectors it must do so within this time limit. If the drive
> takes longer than this period the controller will flag it as bad and
> kick it out of the array. The assumption here is that a drive taking
> that long to respond has a problem and should be replaced.
>
> Most consumer drives have no such timeout limit. They will churn
> forever attempting to recover an unreadable sector. Thus routine errors
> on consumer drives often get them kicked instantly when used on read
> RAID controllers.

Why would I be pulling your leg? I have never had opportunity to work
with real raid cards. Nor have I ever heard anyone say that before.
The highest end I have used was I believe a Highpoint card, about
~$150 range, which was fakeRAID (and I believe the drives
attached to that were enterprise drives anyway)

Thanks for the info.

Kelly Clowers


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/CAFoWM=9wo+94Mpy0j4_WKFdtwCZR9eQ4OaZk9PTwZHpYq10xb w@mail.gmail.com

'Solved' is not a proper description. Better to say that I have
discovered some serious misunderstanding on my part. It would be
a serious waste of other peoples time to extend this sub-thread
with a detailed explanation.

Sorry.
--
Paul E Condon
pecondon@mesanetworks.net


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120915042127.GA612@big.lan.gnu">http://lists.debian.org/20120915042127.GA612@big.lan.gnu

Martin Steigerwald wrote:
> Am Freitag, 7. September 2012 schrieb Bob Proulx:
> > Unfortunately I have some recent FUD concerning xfs. I have had some
> > recent small idle xfs filesystems trigger kernel watchdog timer
> > ...
> > due to these lockups. Squeeze. Everything current. But when idle it
> > would periodically lock up and the only messages in the syslog and on
>
> Squeeze and everything current?
> No way. At least when using 2.6.32 default squeeze kernel. Its really old.
> Did you try with the latest 3.2 squeeze-backports kernel?

But in the future when when Debian Jessie is being released I am going
to be reading then on the mailing list about how old and bad Linux 3.2
is and how it should not be used because it is too old. How can it be
really good now when it is going to be really bad in the future when
supposedly we know more then than we do now? :-)

For my needs Debian Stable is a really very good fit. Much better
than Testing or Unstable or Backports.

Meanwhile I am running Sid on my main desktop machine. I upgrade it
daily. I report bugs as I find them. I am doing so specifically so I
can test and find and report bugs. I am very familiar with living on
Unstable. Good for developers. Not good for production systems.

Bob

On Sat, Sep 15, 2012 at 1:36 AM, Bob Proulx <bob@proulx.com> wrote:
>
> Meanwhile I am running Sid on my main desktop machine. I upgrade it
> daily. I report bugs as I find them. I am doing so specifically so I
> can test and find and report bugs.

Wow, impressive. I run unstable+experimental, but I think I have
reported maybe two or three bugs against it in the years I have
used it. I don't know if I even reported it when there where those
really nasty hard system lockups in X. Yes, I am a terrible person.

Cheers,
Kelly Clowers


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/CAFoWM=-vZJxypMxGVSn6obCM=ogWFYAgvusrfh0RvDtGY55XWA@mail.g mail.com

On 9/15/2012 3:36 AM, Bob Proulx wrote:

> But in the future when when Debian Jessie is being released I am going
> to be reading then on the mailing list about how old and bad Linux 3.2
> is and how it should not be used because it is too old.

So what you're saying here is that Jessie should be released with the
2.6.32 kernel of Squeeze because we already know how bad it is. Thus
the Jessie kernel won't go from "good" to "bad" causing widespread
depression and suicide amongst Debian users.

--
Stan


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 5054E829.40509@hardwarefreak.com">http://lists.debian.org/5054E829.40509@hardwarefreak.com

Stan Hoeppner wrote:
> Bob Proulx wrote:
> > But in the future when when Debian Jessie is being released I am going
> > to be reading then on the mailing list about how old and bad Linux 3.2
> > is and how it should not be used because it is too old.
>
> So what you're saying here is that Jessie should be released with the
> 2.6.32 kernel of Squeeze because we already know how bad it is.

No. I am saying that Jessie should release with the Linux 4.1 kernel
because I am sure we will all agree that a Linux 4.1 kernel would be
awesome and so much better than the 3.2 kernel.

> Thus the Jessie kernel won't go from "good" to "bad" causing
> widespread depression and suicide amongst Debian users.

Hopefully we haven't had widespread suicide amongst users. Instead
perhaps more like a diabetic coma due to depression causing an
increased consumption of chocolate. Massive amounts of chocolate!
The true cure for depression.

Isn't it depressing how a kernel goes from high praise to low disdain
in only a very short time. Is the Linux kernel made from bananas? I
think it might be. It seems to turn brown so very quickly. I wonder
if it is mildly radioactive too? That might explain a lot. It does
seem to have a half life.

Bob