Scott Adametz
2010-Jan-24 04:47 UTC
[Lustre-discuss] Using SSDs for OSS Read Cache on servers with little RAM?
Any possibility to redirect Lustre''s OSS Cache or portions of the Linux pagecache to a location other than RAM such as to an internal SSD (perhaps even two in RAID0). I ask because the servers we have available (read: second hand servers) for OSSs physically max out at 8GB RAM. The wiki states: *"It uses a regular Linux pagecache to store the data."* I looked into pagecache and pdflush tunables but found little on directing the actual location of the cached content as it tends to focus heavily on tuning timing of writes-*to*-disk vs reads. Yes, I understand the absurdity of trying to redirect RAM cached content back to "disk" but with rapidly evolving SSD design and performance it actually makes some sense in this case for Lustre cache data. Obviously I would prefer to redirect *only*Lustre OSS cache data and not the entire Operating System page cache. While an SSD is nowhere near as quick as RAM, it would still seem beneficial to have more frequently viewed content available for reads even from an SSD vs a spinning disk, especially with our use case (HD video editing and playback). Until SSD prices come down to reasonable levels and we can afford to replace all spinning disks with SSDs, any little bit helps ;-) In sum: just a thought to be able to designate, in Lustre configs, an additional low-latency "swap" or "cache" location on the OSSs. Adding one SSD to each OSS sure beats having to buy new servers with more RAM capacity or using all SSD drives and blowing the budget... Thanks for the time, Scott Adametz Systems Engineer Big Ten Network FOX Networks Group scott.adametz at fox.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.lustre.org/pipermail/lustre-discuss/attachments/20100123/253ec2da/attachment.html
Aaron Knister
2010-Jan-25 03:38 UTC
[Lustre-discuss] Using SSDs for OSS Read Cache on servers with little RAM?
One more reason I can''t wait for ZFS to become available as lustre''s underlying filesystem :) On Jan 23, 2010, at 11:47 PM, Scott Adametz wrote:> Any possibility to redirect Lustre''s OSS Cache or portions of the Linux pagecache to a location other than RAM such as to an internal SSD (perhaps even two in RAID0). I ask because the servers we have available (read: second hand servers) for OSSs physically max out at 8GB RAM. > > The wiki states: "It uses a regular Linux pagecache to store the data." I looked into pagecache and pdflush tunables but found little on directing the actual location of the cached content as it tends to focus heavily on tuning timing of writes-to-disk vs reads. Yes, I understand the absurdity of trying to redirect RAM cached content back to "disk" but with rapidly evolving SSD design and performance it actually makes some sense in this case for Lustre cache data. Obviously I would prefer to redirect only Lustre OSS cache data and not the entire Operating System page cache. > > While an SSD is nowhere near as quick as RAM, it would still seem beneficial to have more frequently viewed content available for reads even from an SSD vs a spinning disk, especially with our use case (HD video editing and playback). Until SSD prices come down to reasonable levels and we can afford to replace all spinning disks with SSDs, any little bit helps ;-) > > In sum: just a thought to be able to designate, in Lustre configs, an additional low-latency "swap" or "cache" location on the OSSs. Adding one SSD to each OSS sure beats having to buy new servers with more RAM capacity or using all SSD drives and blowing the budget... > > Thanks for the time, > > Scott Adametz > Systems Engineer > Big Ten Network > FOX Networks Group > scott.adametz at fox.com _______________________________________________ > Lustre-discuss mailing list > Lustre-discuss at lists.lustre.org > http://lists.lustre.org/mailman/listinfo/lustre-discuss-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.lustre.org/pipermail/lustre-discuss/attachments/20100124/4a501ae1/attachment-0001.html