[email protected]
[Top] [All Lists]

Re: [zfs-discuss] Sun Flash Modules

Subject: Re: [zfs-discuss] Sun Flash Modules
From: Tomasz Torcz
Date: Sun, 19 Apr 2009 00:44:23 +0200
On Sat, Apr 18, 2009 at 10:38 PM, Andrew Gabriel
<[email protected]> wrote:
> Bob Friesenhahn wrote:
>> On Sat, 18 Apr 2009, Eric D. Mudama wrote:
>>> What is tall about the SATA stack?  There's not THAT much overhead in
>>> SATA, and there's no reason you would need to support any legacy
>>> transfer modes or commands you weren't interested in.
>> If SATA is much more than a memcpy() then it is excessive overhead for a
>> memory-oriented device.  In fact, since the "device" is actually comprised
>> of quite a few independent memory modules, it should be possible to schedule
>> I/O for each independent memory module in parallel.  A large storage system
>> will be comprised of tens, hundreds or even thousands of independent memory
>> modules so it does not make sense to serialize access via legacy protocols.
>>  The larger the storage device, the more it suffers from a serial protocol.
> It's a mistake to think that flash looks similar to RAM. It doesn't in lots
> of ways -- actually it looks more similar to a hard disk in many respects;-)

 That's true, but flash isn't hard disk either. Flash is flash and I
believe poster
meant exposing it for the OS to consume. This way OS can grow and use
generic Flash Translation Layer for wear levelling and block remapping and
filesystem could use flash features directly. This way for example TRIM commands
could be implemented in this FTL layer anfd won't be hidden in proprietary
firmware. The less magic, blackbox firmwares and more open source code, the
 If I am not clear, here is longer article on this topic:

Tomasz Torcz
xmpp: [email protected]
zfs-discuss mailing list
[email protected]

<Prev in Thread] Current Thread [Next in Thread>