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

Re: TAKE - fix bug 193, oops in fsstress on extended attributes

To: linux-xfs@oss.sgi.com
Subject: Re: TAKE - fix bug 193, oops in fsstress on extended attributes
From: George Georgalis <georgw@galis.org>
Date: Mon, 2 Dec 2002 21:52:41 -0500
In-reply-to: <200212022031.gB2KVcs13886@jen.americas.sgi.com>
References: <200212022031.gB2KVcs13886@jen.americas.sgi.com>
Sender: linux-xfs-bounce@oss.sgi.com
User-agent: Mutt/1.3.28i

On Mon, Dec 02, 2002 at 02:31:38PM -0600, Steve Lord wrote:
>when logging attribute extents, use the correct size for the allocation!
>This got introduced back on Oct 10th when in memory extents where
>changed to be host byte ordered. An incorrect size was used on an allocation.

Just curious, what sort of bugs might surface on a heavily stressed
disk that would not otherwise come up? I know this is a very general
question, sorry, I'm only looking for comments; nothing comes to mind,
short of a 'data is faster than the disk' scenario, but even then wouldn't
the problem be handed to memory/virtual memory?

// George

-- 
GEORGE GEORGALIS, System Admin/Architect    cell: 347-451-8229 
Security Services, Web, Mail,            mailto:george@galis.org 
Multimedia, DB, DNS and Metrics.       http://www.galis.org/george

References:
- TAKE - fix bug 193, oops in fsstress on extended attributes
  - From: Steve Lord <lord@sgi.com>

Prev by Date: [Bug 200] xfs_check should set the exit code to non-zero if the filesystem does not check out
Next by Date: Re: xfs_check exit code?
Previous by thread: TAKE - fix bug 193, oops in fsstress on extended attributes
Next by thread: [Bug 193] when tested with fsstress in scsi, the process is locked.
Index(es):
- Date
- Thread