Message-ID: <4089875F.1010207@techsource.com>
Date: Fri, 23 Apr 2004 17:15:11 -0400
From: Timothy Miller <miller@techsource.com>
MIME-Version: 1.0
To: Joel Jaeggli <joelja@darkwing.uoregon.edu>
CC: Paul Jackson <pj@sgi.com>, tytso@mit.edu, miquels@cistron.nl,
       linux-kernel@vger.kernel.org
Subject: Re: File system compression, not at the block layer
References: <Pine.LNX.4.44.0404231300470.27087-100000@twin.uoregon.edu>
In-Reply-To: <Pine.LNX.4.44.0404231300470.27087-100000@twin.uoregon.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1173
Lines: 32


Joel Jaeggli wrote:
> On Fri, 23 Apr 2004, Paul Jackson wrote:
> 
> 
>>>SO... in addition to the brilliance of AS, is there anything else that 
>>>can be done (using compression or something else) which could aid in 
>>>reducing seek time?
>>
>>Buy more disks and only use a small portion of each for all but the
>>most infrequently accessed data.
> 
> 
> faster drives. The biggest disks at this point are far slower that the 
> fastest... the average read service time on a maxtor atlas 15k is like 
> 5.7ms on 250GB western digital sata, 14.1ms, so that more than twice as 
> many reads can be executed on the fastest disks you can buy now... of 
> course then you pay for it in cost, heat, density, and controller costs. 
> everthing is a tradeoff though.


I had this idea of packing a bunch of those really tiny Toshiba 
quarter-sized drives and some sort of RAID0 controller into a box the 
size of a 3.5" hard drive.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/