Tomasz Torcz wrote:
On Sat, Apr 18, 2009 at 10:38 PM, Andrew Gabriel
<agabr...@opensolaris.org> 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
better.
If I am not clear, here is longer article on this topic:
http://lwn.net/Articles/276025/
I'm somewhat skeptical about designing for the exact nature of today's
flash nand technology too far up the stack. You'll probably find your
efforts have been obsoleted by changes in the underlying flash
technology before you even get as far as debugging your efforts.
There's a big effort across the industry to advance flash technology in
many directions, and the limitations of todays flash technology are
probably just transitory en route, which I expect will move on quickly.
--
Andrew
|
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
