On Wed, Mar 07, 2012 at 09:51:27AM +0100, Lukas Czerner wrote: > Exactly, first we have to define what we actually need to achieve with > it. Not just randomly making up stupid pseudo-optimizations. Moreover > there is _no way_ file system has the information about the HSM nor the > flash regions, fast regions or whatever, it does not even know where is > the beginning of the disk. Stop constructing building from the roof!! > There just is not any interface for the file system to use to get such > information! I'm not really worried about this problem. This is something which can easily be set by the system administrator via mkfs or tune2fs. And just as we now have /sys/block/sda/queue/rotational so that upper layers can make optimizations based on whether or not a disk is an SSD, as we can prove that manual configuration of storage attributes can make a measurable difference, it can be a spur to the standards bodies to eventually (years and years and years later) come up with a standardized way for the file system to get such interfaces automatically. In the meantime, we have flash vendors (or at least one flash vendor who works with embedded/handset customers) interested in potentially providing private interfaces to make additional storage attributes available, or for file systems to provide information to the storage devices so they can better optimize their behaivor. So I'm not too worried about the fact that we don't have a way to specify all of these things yet. If we can find a way to make things faster, eventually the rest of the infrastructure can get plumbed in. (Even standards bodies that move in geologic time scales. :-) > I also believe that regarding HSM user is in no damn position to decide > whether his file will be on flash or not. It just does not work that > way, every user's, or application's files has to be accessed faster than > others from their point of view. Access control is going to be an interesting problem, and what the requirements are for a file system running on an HPC system, or an Android device, or a generic time-sharing system are quite different. Given that many of us have grown up in an environment where there are mutually suspicious (and untrustworthy) time sharing users, or equally untrustworthy application writers who tend to optimize their application without considering anything else, it's easy for us to assume that if we can't solve the authorization problem completely, that it's hopeless. But the same argument can be made for real time scheduling priorities (which is even easier for untrustworthy application authors to abuse), but that's turned out to be extremely important in allowing Linux to break through in various new fields --- including Naval Warships and laser-wielding industrial robots. :-) - Ted -- 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
