>>> On Thu, 20 Oct 2005 13:01:29 -0700, Dave Pifke >>> <[EMAIL PROTECTED]> said:
dave> Indeed; we're using a 3ware SATA RAID card. I like the 3wares too... dave> As for the fsck time, I haven't had to do it yet, but I'm dave> sure it will take a while. (On some other machines with dave> similar size filesystems using reiserfs, an fsck takes dave> upwards of 12 hours and frequently exhausts 4GB of RAM.) Someone reported 75 days on a similar sized 'ext3' filesystem (there was a bit of a special case, but many days is not unusual): http://UKAI.org/b/log/debian/snapshot/failed_to_repair_disk-2005-06-18-20-05.html http://UKAI.org/b/log/debian/snapshot/1_month_fsck-2005-07-22-00-00.html http://UKAI.org/b/log/debian/snapshot/fsck_completed_but-2005-09-04-15-00.html ReiserFS 'fsck' is a bit notorious for taking time and space; I am astonished that it is only 12 hours with it. But I am really curious on the time/size for JFS. dave> [ ... ] My guess is that 0.1% of our photo storage makes dave> up a double-digit percentage of the load - cutting that by dave> a factor of 10 makes a huge difference. That's somewhat plausible. >> File system caching except for the top levels of the tree and >> some metadata is usually pointless anyhow. dave> This is interesting to me and deserves further study. Well, unless you can cache the whole set anyhow, if only 2GB of data get actually used in a day out of 2TB, then it is good. But even if the popularity is very skewed it is somewhat unlikely. Also note that for thumbnails you are using a 4KiB page per each one... dave> Given the slow seek time of big 7200RPM SATA drives, it dave> seems like being able to serve the file from memory would dave> be a huge win. (We're advertiser-supported - barring a dave> surge in people willing to pay $20CPM rates for banner dave> ads, the photos aren't going to be stored on 15K SCSI dave> drives any time soon. <g>) You don't need them, there is a trick! Access time is a combination of seeking across cylinders and rotational latency. You can't do much for rotational latency, but you can improve seek time _a lot_. Because some suspect that there is a dirty little secret: fast seek time drives like those 15k SCSI drives are actually either 2.5" drives or they are 3.5" drives in which only the outer cylinders are used. Whatever, the «slow seek time of big 7200RPM SATA drives» is such because they have lots of cylinders and the arm has to move a long way (a full stroke is hell) across them (there are other factors like settling time). The trick is that you can just use the last (outer) 1/2 or 1/3 of cylinders and get really amazing seek times even from those drives. Considering how cheap they are, using only 1/2 or 1/3 of their capacity might be a rather worthwhile tradeoff. >> Conversely one could explore storing the thumbnails in a >> GDBM/Berkeley DB/... hash database and probably the 50-100KB >> range images too. dave> A clever idea, probably worth prototyping to get some dave> benchmarks. Also because your 1KiB thumbnails really should not end up in 4KiB blocks by themselves... Think seek times for example. dave> As with some discussions we've had internally about using dave> Apache's mod_mem_cache to cache things [ ... ] Another thing I would strongly consider is to switch to a much lower overhead HTTP server, one specifically designed to serve static content fast, for example Boa or 'thttpd': http://WWW.Boa.org/ http://WWW.ACME.com/software/thttpd/ But if you use the Berkeley DB alternative for the thumbnail or something similar you could alternatively use the Perl module that does HTTP service and have a special purpose 20 line Perl program server that just serves thumbnails. With some complications if you want to run multithreaded. [ ... ] ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Jfs-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jfs-discussion
