Hi Gábor, On Wed, 2008-02-13 at 15:40 +0100, Gergely Gábor wrote: > This release works flawlessly for me, for over 4 hours now. No memory > leak, no deadlock occured, as I tested the previously malfunctioning > scenarios.
Good news! We might finally see daylight for the stable release. On Thu, 2008-02-14 at 01:02 +0100, Gergely Gábor wrote: > I have left my computer working, testing nilfs. I have found that > after a log period of time, most of the memory in the computer vas > allocated as cache (according to vmstat) and even aftel killing all > processes that held files open, the amount (~430 megabytes) did not > decrease significantly. I have unmounted the filesystem, and most > cache was freed up, ... > This leads to the assumption, that some data is left cached, even > when not in use. To reproduce this behaviour, I simply started > "vmstat 1", and rtorrent, started a download, and watched the cache > consumption climb. after exiting rtorrent, most of the cache is not > reclaimed, not even after a long period of time. Yeah, this is the peculiar behaviour of Linux memory management. Linux try to devote free memory to the page cache wherever possible. > (i understand, that leaving blocks in the cache is preferable for > a log structured fs, as that reduces seeks necessary for reading, > but possibly some aging mechanism, and/or a maximum cache size > option would be a good idea to implement in the future, if not yet done) As I commented above, the bahaviour that leaves blocks in the cache, is the nature of Linux, and basically its control is supposed to be the matter of the Linux mm and applications. For example, applications can invalidate the cache through posix_fadvice() or madvise() system call, and users can tune the cache behaviour through /sbin/sysctl vm.* or /proc/sys/vm/*. Of course, we are taking full advantage of the nature for NILFS to compensate the drawback that logfs incurs performance penalty for reads. And I believe that this cache behaviour is harmless because most of cached pages are reclaimable any time if not modified. However, a memory leak must be distinguished because it blows up this scheme. I'm nervous about it if suspicious. So, now I'm relieved to hear your report. > Sorry for flooding the mail list with my self-contradictory status reports. Don't mind. Your reports are very helpful. > Please tell me, where can i read about the architecture of nilfs2 > in greater detail, other than the code? (i'm willing to understand > the code as well, but i'd need some guidance, where to start. > I'd be the most happy if i could provide some more useful help > rather than constant "complaining") has many things changed since > nilfs1? (i have found papers about that on the project homepage) One of my colleage is writing a paper of nilfs2, and I believe it would satisify these requests. Sincerely, -- Ryusuke Konishi NILFS team NTT http://www.nilfs.org/ _______________________________________________ users mailing list [email protected] https://www.nilfs.org/mailman/listinfo/users
