[Tig] St. Diig

[timothy norman huber]

Bob,

...so many question, too much wine.  (peppery '02 petit syrah and a  
dusty '01 rioja)

I can and will answer all of your questions- in the morning

until then...

( zfs...I knew you'd bring that up- cool stuff IMFUO)

T


On Oct 18, 2007, at 7:26 PM, Bob Friesenhahn wrote:

> On Thu, 18 Oct 2007, timothy norman huber wrote:
>>
>> We're working on the I/O bottleneck at Violin.
>>
>> Right now we've got 1/2 TB of DRAM in 2U connecting via PCIe.
>
> Speaking of I/O bottleneck, since DRAM is volatile, how long does  
> it take to load data into that 1/2 TB of DRAM from traditional disk  
> or tape so that actual work can be started?  How long does it take  
> to copy the finished work from 1/2 TB of DRAM to backing disk?
>
> FLASH devices are non-volatile but they also tend to wear out after  
> many repeated writes, which is a common pattern in some usage  
> models. That is not to say that hard drives don't wear out, but  
> their failure mechanisms are different and time to fail is not  
> really coupled to the amount of accesses.
>
> How many times may the type of FLASH memory used for such large  
> storage be repeatedly written before failures start to occur?
>
> What is the MTBF per field replaceable component, MTBF for a full  
> 2U unit, and how difficult is the device to repair?  Can the device  
> continue operating while a failing component is replaced?
>
> It is interesting that filesystem design has a quite a lot to do  
> with how many writes occur per sector.  A copy-on-write filesystem  
> like Sun's ZFS is going to write each location on disk less often  
> than a filesystem which updates by overwriting existing data.  Some  
> filesystems put their "FAT" or superblocks at fixed locations so  
> they will wear out those areas much faster.
>
>> Random I/O kills even the fastest HDD technology.  15k drives have
>
> This is definitely true, but most post-production/DI tasks do  
> hardly any random I/O at all.  Most accesses are sequential and use  
> the full block size.  Sequential throughput drives performance for  
> DI work.
>
> Random I/O performance is vital for database storage
>