porting tmpfs

Nikita Glukhov a63fvb48 at gmail.com
Sat Nov 14 02:43:49 PST 2009


Hi.

In July, I’ve fixed file truncating bug.  The problem was the lack of
a call to vtruncbuf() in tmpfs_reg_resize().  Now tmpfs survives
testing with fsx and fsstress.  But also I found some bug at
fsstress.c: in function creat_f() line 1684 "add_to_flist(type, id,
parid);" must be after the following line "#endif".  Without this
change fsstress does not remember files that it is created and no
reading/writing is performed. (“no filename” error is displayed in
verbose mode.)

Also I don’t understand why Alex Hornung has removed tmpfs_spec_vnops.
Without adding this ops call to mknod() ends with panic. (I have to
run fsstress with option “–f mknod=0”.)

Next I tried to use objcache instead of plain kmalloc() to allocate
tmpfs nodes and direntries.  But when objcache is destroyed during
unmount, there is a crit_panic "td_pri is/would-go negative! -26"
caused by mag_purge() calling crit_exit() at objcache.c. It seems that
mag_purge() is not called from the critical section as it is expected.

tmpfs now really takes double memory space. I tried to implement page
moving between VM objects but I’ve never seen buffer passed to
tmpfs_strategy() with B_RELBUF set. All my attempts to modify buffer
flags in tmpfs_read() end with global deadlock.

2 diffs to Alex Hornung's tree are attached: first uses kmalloc(),
second uses objcache.
Attachment:
tmpfs.diff
Description: Binary data
Attachment:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bin00002.bin
Type: application/octet-stream
Size: 21114 bytes
Desc: "Description: Binary data"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20091114/571e5c85/attachment-0030.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bin00001.bin
Type: application/octet-stream
Size: 17237 bytes
Desc: "tmpfs-objcache.diff"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20091114/571e5c85/attachment-0031.bin>


More information about the Kernel mailing list