tmpfs panic

[Dmitry Morozovsky]

On Sun, 15 Jun 2008, Kostik Belousov wrote:

KB> > Also, I can observe tmpfs is doing non-optimal; I did not found
KB> > straight ways to set block/frag size; I suppose for most tmpfs usage
KB> > they should be decreases to the lowest values, such as 4k/512 -- what
KB> > do you think?
KB> Block and fragment size concepts are not applicable to the tmpfs;
KB> basically, this is the point for having such fs in the system. Each file
KB> on the tmpfs is presented as the swap-backed vm object.
KB> 
KB> Besides the set of the (mostly) known problems with correctness and
KB> stability, current implementation has quite unefficient implementation
KB> of the mmap and buffer cache interaction. The vm object (and pages) used
KB> for the vm operations are copied from the backing vm object instead of
KB> being reused. This means that we get essentially twice as much memory
KB> used, and copying.

This, actually, was simple observations: svn base tree over ZFS comsumes a bit 
less than 2G, and after rsync -aH to tmpfs, repoted by du, it seems to eat 
approx 4G (with comparable inode cound as reported by find)


Sincerely,
D.Marck                                     [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer:                                 marck at FreeBSD.org ]
------------------------------------------------------------------------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck at rinet.ru ***
------------------------------------------------------------------------