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/ -- Tomasz Torcz xmpp: zdzich...@chrome.pl _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
