Hi, > No, I can't comment on any of that. This isn't about any particular piece > of technology; it's an observation that there are a lot of technologies > that seem to fit in this niche; some of them are even available to > buy today. > > No statement of mine should be taken as an indication of any future > Intel product plans :-) > Ok. I understand. :-) > > There are a number of interesting non-volatile memory (NVM) technologies > > > being developed. Some of them promise DRAM-comparable latencies and > > > bandwidths. At Intel, we've been thinking about various ways to present > > > those to software. > > We can be more and more radical in the case of new NVM technologies, I think. The non-volatile random access memory with DRAM-comparable read and write operations' latencies can change computer world dramatically. Just imagine a computer system with only NVM memory subsystem (for example, it can be very promising mobile solution). It means that we can forget about specified RAM and persistent storage solutions. We can keep run-time and persistent information in one place and operate it on the fly. Moreover, it means that we can keep any internal OS's state persistently without any special efforts. I think that it can open new very interesting opportunities. The initial purpose of a filesystem is to distinguish run-time and persistent information. Usually, we have slow persistent memory subsystem (HDD) and fast run-time memory subsystem (DRAM). Filesystem is a technique of synchronization a slow persistent memory subsystem with fast run-time memory subsystem. But if we will have a fast memory that can keep run-time and persistent information then it means a revolutionary new approach in memory architecture. It means that two different entities (run-time and persistent) can be one union. But for such joined information entity traditional filesystems' and OS's internal techniques are not adequate approaches. We need in revolutionary new approaches. From NVM technology point of view, we can be without filesystem completely, but, from usual user point of view, modern computer system can't be imagined without filesystem. We need in filesystem as a catalogue of our persistent information. But OS can be represented as catalogue of run-time information. Then, with NVM technologies, the OS and filesystem can be a union entity that keeps as persistent as run-time information in one catalogue structure. But such representation needs in dramatically reworking of OS internal techniques. It means that traditional hierarchy of folders and files is obsolete. We need in a new information structure approaches. Theoretically, it is possible to reinterpret all information as run-time and to use OS's technique of internal objects structure. But it is impossible situation from end users point of view. So, we need in filesystem layer anyway as layer which represent user information and structure of it. If we can operate and keep internal OS representation of information then it means that we can reject file abstraction. We can operate by information itself and keep information without using different files' formats. But it is known that all in Linux is a file. Then, factually, we can talk about completely new OS. Actually, NVM technologies can support possibility doesn't boot OS completely. Why does it need to boot if it is possible to keep any OS state in memory persistently? I think that OS booting can be obsolete thing. Moreover, it is possible to be without swapping completely because all our memory can be persistent. And for system with NVM memory only request queue and I/O scheduler can be obsolete thing. I think that kernel memory page approach can be redesign significantly, also. Such thing as shared libraries can be useless because all code pieces can be completely in memory. So, I think that all what I said can sound as a clear fantasy. But, maybe, it needs to discuss about new OS instead of new filesystem. :-) With the best regards, Vyacheslav Dubeyko. -- 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
