On Fri, Nov 02, 2012 at 01:10:48PM -0700, Darrick J. Wong wrote: > On Fri, Nov 02, 2012 at 04:41:09PM +0800, Zheng Liu wrote: > > On Fri, Nov 02, 2012 at 02:38:29PM +0800, Zhi Yong Wu wrote: > > > Here also has another question. > > > > > > How to save the file temperature among the umount to be able to > > > preserve the file tempreture after reboot? > > > > > > This above is the requirement from DB product. > > > I thought that we can save file temperature in its inode struct, that > > > is, add one new field in struct inode, then this info will be written > > > to disk with inode. > > > > > > Any comments or ideas are appreciated, thanks. > > > > Hi Zhiyong, > > > > I think that we might define a callback function. If a filesystem wants > > to save these data, it can implement a function to save them. The > > filesystem can decide whether adding it or not by themselves. > > > > BTW, actually I don't really care about how to save these data because I > > only want to observe which file is accessed in real time, which is very > > useful for me to track a problem in our product system. > > <shrug> I _think_ the vfs quota code simply asks the filesystem for a special > inode where it save the quota data in whatever (FS-agnostic) format it wants. > Have you considered something like that? Doesn't make a lot of sense because the data is per-inode. Storing it per-inode is the only way it can be efficiently stored and indexed as it is accessed at the same time the inode is accessed. Quota information, OTOH, is per user/group/project - they are shared structures and have a completely different lookup and index mechanism to per-inode data structures. Henc eI don't think that the quota model would be a good fit for such data. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
