[prev in list] [next in list] [prev in thread] [next in thread]
List: jfs-discussion
Subject: Re: [Jfs-discussion] Chronic logredo failed (rc=-231) errors
From: Steve Costaras <stevecs () chaven ! com>
Date: 2010-01-08 0:04:34
Message-ID: 4B467692.60409 () chaven ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Yeah, I created sparse file systems with JFS as well before I attempted
to actually create a real one. The sparse file actually worked. It's
when I really had the drives and created a real system when it blew
chunks. Only so much that can be tested without actually doing it I
guess. Anyway, just mentioned it as a data point to be careful. I
sent the info at the time to Shaggy in hopes he was able to take a look
at it, unfortunately, I needed to get a workable system on-line so had
to find an alternative (xfs).
On 01/07/2010 17:58, Andi Kleen wrote:
> Steve Costaras<stevecs@chaven.com> writes:
>
>> Everything here is 64bit and memory was not the issue. It seems just
>> that the various tools were never tested with such large volumes.
>>
> I did some testing a long time ago (when working on the 2.4 64bit kernel)
> by creating holey loopback files that very large and creating file systems
> on it. That allows to simulate very large volumes, but of course
> not fill them.
>
> Back then JFS and XFS were the only ones even in running, the others
> didn't work at all for various reasons.
>
> I don't remember the exact sizes I tested, but iirc it was> 100TB.
>
> That was simple a mkfs + mount + create some small files test.
>
> It already needs JFS or XFS to just contain the holey backing file.
>
> -Andi
>
[Attachment #5 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<font face="Courier New"><br>
Yeah, I created sparse file systems with JFS as well before I attempted
to actually create a real one. The sparse file actually \
worked. It's when I really had the drives and created a real system when \
it blew chunks. Only so much that can be tested without actually \
doing it I guess. Anyway, just mentioned it as a data point to be
careful. I sent the info at the time to Shaggy in hopes he was able
to take a look at it, unfortunately, I needed to get a workable system
on-line so had to find an alternative (xfs).<br>
<br>
<br>
</font><br>
On 01/07/2010 17:58, Andi Kleen wrote:
<blockquote cite="mid:87vdfdmprh.fsf@basil.nowhere.org" type="cite">
<pre wrap="">Steve Costaras <a class="moz-txt-link-rfc2396E" \
href="mailto:stevecs@chaven.com"><stevecs@chaven.com></a> writes: </pre>
<blockquote type="cite">
<pre wrap="">
Everything here is 64bit and memory was not the issue. It seems just
that the various tools were never tested with such large volumes.
</pre>
</blockquote>
<pre wrap="">
I did some testing a long time ago (when working on the 2.4 64bit kernel)
by creating holey loopback files that very large and creating file systems
on it. That allows to simulate very large volumes, but of course
not fill them.
Back then JFS and XFS were the only ones even in running, the others
didn't work at all for various reasons.
I don't remember the exact sizes I tested, but iirc it was > 100TB.
That was simple a mkfs + mount + create some small files test.
It already needs JFS or XFS to just contain the holey backing file.
-Andi
</pre>
</blockquote>
</body>
</html>
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Jfs-discussion mailing list
Jfs-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jfs-discussion
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic