public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
* attack upon XFS, misinformation abounds, linux-raid list
@ 2013-06-09 10:46 Stan Hoeppner
  2013-06-09 12:13 ` Ric Wheeler
                   ` (3 more replies)
  0 siblings, 4 replies; 7+ messages in thread
From: Stan Hoeppner @ 2013-06-09 10:46 UTC (permalink / raw)
  To: xfs@oss.sgi.com

In a recent linux-raid list thread here:
http://marc.info/?l=linux-raid&m=137072140106867&w=2

seriously flawed arguments against the reliability of XFS, and even the
performance of XFS, are made.  The OP even quotes Dave's LCA
presentation as a performance reason to avoid XFS.  The party really
gets started at paragraph 7.

I made a brief effort to debunk his claims and explained that he can't
have O_PONIES, that he should use fsync or O_DIRECT, etc for data
safety.  To non experts/advanced filesystem users, his long winded
argument may be persuasive.  Obviously none of you experts has time to
debunk every such post, but this one may be worth a read at least,
especially given the weight Google gives to vger lists.

-- 
Stan


_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: attack upon XFS, misinformation abounds, linux-raid list
  2013-06-09 10:46 attack upon XFS, misinformation abounds, linux-raid list Stan Hoeppner
@ 2013-06-09 12:13 ` Ric Wheeler
  2013-06-10  9:43 ` Stefan Ring
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 7+ messages in thread
From: Ric Wheeler @ 2013-06-09 12:13 UTC (permalink / raw)
  To: xfs

On 06/09/2013 06:46 AM, Stan Hoeppner wrote:
> In a recent linux-raid list thread here:
> http://marc.info/?l=linux-raid&m=137072140106867&w=2
>
> seriously flawed arguments against the reliability of XFS, and even the
> performance of XFS, are made.  The OP even quotes Dave's LCA
> presentation as a performance reason to avoid XFS.  The party really
> gets started at paragraph 7.
>
> I made a brief effort to debunk his claims and explained that he can't
> have O_PONIES, that he should use fsync or O_DIRECT, etc for data
> safety.  To non experts/advanced filesystem users, his long winded
> argument may be persuasive.  Obviously none of you experts has time to
> debunk every such post, but this one may be worth a read at least,
> especially given the weight Google gives to vger lists.

Thanks for pointing that out - I responded as well.

Funny that he decided to use ext4 after basing it on a google search for "xfs 
zero" and did not bother to the same query with "ext4 zero length files" :)

Ric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: attack upon XFS, misinformation abounds, linux-raid list
  2013-06-09 10:46 attack upon XFS, misinformation abounds, linux-raid list Stan Hoeppner
  2013-06-09 12:13 ` Ric Wheeler
@ 2013-06-10  9:43 ` Stefan Ring
  2013-06-10 13:44   ` Eric Sandeen
  2013-06-10 20:02 ` Ben Myers
  2013-06-11  7:12 ` Steve Bergman
  3 siblings, 1 reply; 7+ messages in thread
From: Stefan Ring @ 2013-06-10  9:43 UTC (permalink / raw)
  To: stan; +Cc: xfs@oss.sgi.com

On Sun, Jun 9, 2013 at 12:46 PM, Stan Hoeppner <stan@hardwarefreak.com> wrote:
> In a recent linux-raid list thread here:
> http://marc.info/?l=linux-raid&m=137072140106867&w=2
>
> seriously flawed arguments against the reliability of XFS, and even the
> performance of XFS, are made.  The OP even quotes Dave's LCA
> presentation as a performance reason to avoid XFS.  The party really
> gets started at paragraph 7.
>
> I made a brief effort to debunk his claims and explained that he can't
> have O_PONIES, that he should use fsync or O_DIRECT, etc for data
> safety.  To non experts/advanced filesystem users, his long winded
> argument may be persuasive.  Obviously none of you experts has time to
> debunk every such post, but this one may be worth a read at least,
> especially given the weight Google gives to vger lists.

The really unfortunate thing about this is that the bug[1] which would
prevent transaction flushing from happening got imported and shipped
for a rather long time in RHEL. It's one thing to get a file zeroed
that's a few seconds old, but having the same happen to files which
haven't been touched in hours, even before issuing manual sync, is
certainly not very reassuring.

As a very satisfied user of XFS on CentOS 6, I have been nervous
enough about that to go through the trouble of rebooting our main
server for a kernel upgrade a few weeks ago. Thanks to RedHat's
deceptive tactics regarding kernel patches, I have also not been able
to pin-point the exact range of kernel versions affected by this in a
reasonable amount of time and hence have not found out (thankfully not
the hard way) if it was even necessary.

[1] https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/6.4_Technical_Notes/kernel.html
"BZ#855139"

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: attack upon XFS, misinformation abounds, linux-raid list
  2013-06-10  9:43 ` Stefan Ring
@ 2013-06-10 13:44   ` Eric Sandeen
  0 siblings, 0 replies; 7+ messages in thread
From: Eric Sandeen @ 2013-06-10 13:44 UTC (permalink / raw)
  To: Stefan Ring; +Cc: stan, xfs@oss.sgi.com

On 6/10/13 4:43 AM, Stefan Ring wrote:
> On Sun, Jun 9, 2013 at 12:46 PM, Stan Hoeppner <stan@hardwarefreak.com> wrote:
>> In a recent linux-raid list thread here:
>> http://marc.info/?l=linux-raid&m=137072140106867&w=2
>>
>> seriously flawed arguments against the reliability of XFS, and even the
>> performance of XFS, are made.  The OP even quotes Dave's LCA
>> presentation as a performance reason to avoid XFS.  The party really
>> gets started at paragraph 7.
>>
>> I made a brief effort to debunk his claims and explained that he can't
>> have O_PONIES, that he should use fsync or O_DIRECT, etc for data
>> safety.  To non experts/advanced filesystem users, his long winded
>> argument may be persuasive.  Obviously none of you experts has time to
>> debunk every such post, but this one may be worth a read at least,
>> especially given the weight Google gives to vger lists.
> 
> The really unfortunate thing about this is that the bug[1] which would
> prevent transaction flushing from happening got imported and shipped
> for a rather long time in RHEL. It's one thing to get a file zeroed
> that's a few seconds old, but having the same happen to files which
> haven't been touched in hours, even before issuing manual sync, is
> certainly not very reassuring.

Bugs and regressions are always unfortunate, and this one was no exception.
It was pretty obscure, but we (mostly Dave) worked with our customers
to identify & resolve it within days of the bug report.

As far as I know, the bug existed only for a crash, not a reboot.

> As a very satisfied user of XFS on CentOS 6, I have been nervous
> enough about that to go through the trouble of rebooting our main
> server for a kernel upgrade a few weeks ago. Thanks to RedHat's
> deceptive tactics regarding kernel patches, I have also not been able

deceptive - adj. - Giving an appearance or impression different from the true one; misleading.

which sounds pretty damning.  Perhaps more accurate is:

obfuscated - adj. - Rendered obscure, unclear, or unintelligible ;)

> to pin-point the exact range of kernel versions affected by this in a
> reasonable amount of time and hence have not found out (thankfully not
> the hard way) if it was even necessary.

It was introduced in 6.2 and resolved in 6.4, as well as 6.2
and 6.3 z-stream kernels.  Those are the sorts of things Red Hat support
can help customers identify more quickly & clearly.

-Eric

> [1] https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/6.4_Technical_Notes/kernel.html
> "BZ#855139"
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: attack upon XFS, misinformation abounds, linux-raid list
  2013-06-09 10:46 attack upon XFS, misinformation abounds, linux-raid list Stan Hoeppner
  2013-06-09 12:13 ` Ric Wheeler
  2013-06-10  9:43 ` Stefan Ring
@ 2013-06-10 20:02 ` Ben Myers
  2013-06-11  7:12 ` Steve Bergman
  3 siblings, 0 replies; 7+ messages in thread
From: Ben Myers @ 2013-06-10 20:02 UTC (permalink / raw)
  To: Stan Hoeppner; +Cc: xfs

Hey Stan,

On Sun, Jun 09, 2013 at 05:46:21AM -0500, Stan Hoeppner wrote:
> In a recent linux-raid list thread here:
> http://marc.info/?l=linux-raid&m=137072140106867&w=2
> 
> seriously flawed arguments against the reliability of XFS, and even the
> performance of XFS, are made.  The OP even quotes Dave's LCA
> presentation as a performance reason to avoid XFS.  The party really
> gets started at paragraph 7.
> 
> I made a brief effort to debunk his claims and explained that he can't
> have O_PONIES, that he should use fsync or O_DIRECT, etc for data
> safety.  To non experts/advanced filesystem users, his long winded
> argument may be persuasive.  Obviously none of you experts has time to
> debunk every such post, but this one may be worth a read at least,
> especially given the weight Google gives to vger lists.

I gave it a quick read, but since I'm not on linux-raid I don't have a good way
to reply to Steve.  Could you bounce that message over?  I'd be happy to try to
address a point or two...

Thanks,
	Ben

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: attack upon XFS, misinformation abounds, linux-raid list
  2013-06-09 10:46 attack upon XFS, misinformation abounds, linux-raid list Stan Hoeppner
                   ` (2 preceding siblings ...)
  2013-06-10 20:02 ` Ben Myers
@ 2013-06-11  7:12 ` Steve Bergman
  2013-06-12  1:12   ` Stan Hoeppner
  3 siblings, 1 reply; 7+ messages in thread
From: Steve Bergman @ 2013-06-11  7:12 UTC (permalink / raw)
  To: linux-xfs

Stan Hoeppner <stan <at> hardwarefreak.com> writes:

> but this one may be worth a read at least

How flattering that you felt you needed to seek out reinforcements. :-)

-Steve




_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: attack upon XFS, misinformation abounds, linux-raid list
  2013-06-11  7:12 ` Steve Bergman
@ 2013-06-12  1:12   ` Stan Hoeppner
  0 siblings, 0 replies; 7+ messages in thread
From: Stan Hoeppner @ 2013-06-12  1:12 UTC (permalink / raw)
  To: Steve Bergman; +Cc: linux-xfs

On 6/11/2013 2:12 AM, Steve Bergman wrote:
> Stan Hoeppner <stan <at> hardwarefreak.com> writes:
> 
>> but this one may be worth a read at least
> 
> How flattering that you felt you needed to seek out reinforcements. :-)

More like, "Hay guys, some dude is talking smack about Mom." ;)

Seriously though, expanding the participant list to the devs has been a
positive thing overall, has it not?  Worth noting, I've been a
subscriber to the XFS list for a few years--no seeking was required.

-- 
Stan

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2013-06-12  1:12 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-06-09 10:46 attack upon XFS, misinformation abounds, linux-raid list Stan Hoeppner
2013-06-09 12:13 ` Ric Wheeler
2013-06-10  9:43 ` Stefan Ring
2013-06-10 13:44   ` Eric Sandeen
2013-06-10 20:02 ` Ben Myers
2013-06-11  7:12 ` Steve Bergman
2013-06-12  1:12   ` Stan Hoeppner

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox