Both a top post and bottom post. == Top Post Lost the context for this, but looking at your site: http://code.google.com/p/fscops/ I see a very valuable HSM goal, but I don't see the biggest user of future HSM implementations. Namely servers that add SSD drives as even faster / more expensive storage than rotating disks. The block layer is right now is exposing a flag to user space for rotating / non-rotating. I think it will be in 2.6.29, but it has not been accepted yet I don't think. Since non-rotating media is about 50x the cost of rotating media, I can envision a lot of useres wanting to put fiels that are about to be heavily used onto SSD for processing / searching / etc. then moved back to rotating disk until needed again. I know my companies data usage patterns would benefit greatly from an HSM that support SSD drives. We work with a couple hundred datasets a year typically. But at any given time, just a couple of them are actively in use. >> copy_inode_info() > > Well, currently I dont intend to move the inode to a new location. I > would prefer leave the original inode intact just updating the new > data block pointers. This is still in debate, whether to relocate > inode or not. I know I pseudo coded it up based on a new inode. If your goal is to do the HSM re-org with live files, then I would try real hard not to allocate a new inode. That way after the re-org all of the file i/o will continue to work exactly like it was. Greg -- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
