What Every Data Programmer Needs to Know About Disks
1–10 of 11 posts
Re: What Every Data Programmer Needs to Know About Disks
#2Converted the Presentation PPTX to PDF for accessibility: http://dl.dropbox.com/u/5137/pdf-link/What%20Every%20Data%20...
Re: What Every Data Programmer Needs to Know About Disks
#3Is there a video recorded of the presentation somewhere? This seemed really interesting
Re: What Every Data Programmer Needs to Know About Disks
#4Slide 6: "[Disk] throughput: 768 MB/sec on SATA 3" is misleading, consumer-grade rotating disks barely fill SATA 1 with ~70 MB/sec. SSD are faster in raw transfer, and if you have a RAID you are not limited by a single SATA channel any more.
Slide 13: "Laugh at MongoDB" is pretty stupid, mongo makes certain trade-offs that are not for everyone, but they are still meaningful.
The presentation doesn't explore the RAID options, which is a shame.
Re: What Every Data Programmer Needs to Know About Disks
#5Is there a video recorded of the presentation somewhere? This seemed really interesting
I was really hoping for a video, actually. Audio would suffice too :)
Re: What Every Data Programmer Needs to Know About Disks
#6Slide 6: "[Disk] throughput: 768 MB/sec on SATA 3" is misleading, consumer-grade rotating disks barely fill SATA 1 with ~70 MB/sec. SSD are faster in raw transfer, and if you have a RAID you are not limited by a single SATA channel any more. Slide 13: "Laugh at MongoDB" is pretty stupid, mongo makes certain trade-offs that are not for everyone, but they are still meaningful. The presentation doesn't explore the RAID…
He's referring to the bus speed of SATA 3 as an upper bound -- but like you mentioned, if you throw RAID and such into the mix, I'm not so sure either that it's a very useful number.
Re: What Every Data Programmer Needs to Know About Disks
#7This talk totally failed to properly discuss the issues of the various kinds of fsync, instead (it seems to me) just making a selection of vague comments. That is a shame, as really properly understanding file integrity is a really important issue, which is very easy to get very wrong.
When ext4 came out, I remember a large number of apps losing data, as the metadata and 'normal data' caches can get out of order, meaning that:
Write file B. Rename B -> A.
Can result (after a crash) in A being empty, as the rename can occur before the contents of B are actually written.
Re: What Every Data Programmer Needs to Know About Disks
#8Paint me unimpressed. "eat my Data" was a way, way better and deeper presentation:
http://www.oscon.com/oscon2008/public/schedule/detail/3172
Get the presentation here: http://flamingspork.com/talks/2007/06/eat_my_data.odp
Re: What Every Data Programmer Needs to Know About Disks
#9This talk totally failed to properly discuss the issues of the various kinds of fsync, instead (it seems to me) just making a selection of vague comments. That is a shame, as really properly understanding file integrity is a really important issue, which is very easy to get very wrong. When ext4 came out, I remember a large number of apps losing data, as the metadata and 'normal data' caches can get out of order, mea…
Agreed. These slides are like "Disks are not memory 101". I'd hope the talk went into more details.
After an hour or so reading semi-related material I have an understanding that goes beyond these basics :-/
Re: What Every Data Programmer Needs to Know About Disks
#10Paint me unimpressed. "eat my Data" was a way, way better and deeper presentation: http://www.oscon.com/oscon2008/public/schedule/detail/3172 Get the presentation here: http://flamingspork.com/talks/2007/06/eat_my_data.odp
Thank you for that link. This is a far more interesting presentation than the OT. (Though it does assume some prior knowledge, like what fsync is, etc.)