Editing Development

$ sudo nvram boot-args="-v keepsyms=1 debug=0x144"

By default kmem/vmem require a certain level of performance from the OS page allocator. It is easy to overwhelm the OS X page allocator. We tuned vmem to use a KMEM_QUANTUM of 512Kb chunks of memory from the page allocator rather than the smaller allocations that vmem prefers. This is less than ideal as it reduces the ability for vmem to smoothly release memory to the page allocator when the machine is under pressure. While we have an adequately performing solution now, there will always be a tension between our allocator and OS X itself. OS X only provides minimal mechanisms to observe and respond to memory pressure in the machine, so we are somewhat limited in what can be achieved in this regard.   

 

 

You can clearly see the kind of memory corruption, the actual corrupted data, which kmem cache was involved, the relative time that the last action occurred, and the stack trace for the last action (which was a call to zfs_kmem_free()) - indicating that spl_start() was implicated in the fault. This event would have been logged the next time the modified after free buffer was allocated.

   sudo make test_hw

=== VFS nolocks ===

To avoid deadlocking complications, we do not call VFS with any locks, at any time. This means we differ a little bit from original IllumOS code. In particular, the calls that create a znode (zfs_mknode and zfs_znode_alloc)

we do not attach the vnode here, as we are inside that of a dmu_tx. For example, the VNOPs zfs_create, zfs_mkdir, zfs_symlink and zfs_make_xattrdir, have instead been patched to call zfs_znode_getvnode() to attach the vnode '''after'''

the dmu_tx has been completed.  This means there is a small window where another thread can call zget() on the same object, and it does not yet have the vnode. This is detected in zget, and will delay until the vnode is

attached. We should look into a better delay, perhaps a condvar with wakeup.

There is further work in zil_lwb_commit() to ensure we call zfs_get_data without locks, and vnode attached. This this area also differs somewhat from IllumOS. The zget() call has been extended to allow flags to specify if

we should allow zget on unlinked files zil, and zget without attaching vnode (for delayed attachment after locks are released).

zfs_onexit (as in calls to ''' getf ''' and ''' releasef ''' ) need to place the internal XNU ''struct fileproc'' in the wrapper ''struct spl_fileproc'' , so that '''spl_vn_rdwr()''' can use it to do IO.

including for link (hard links) targets. Due to this, O3X caches the name in the znode so that we can return it without cost in vnop_getattr if available, and fall back to using zap_value_search otherwise.

This value is also set on the vnode in vfs_vget() using the vnode_update_identity() call. This is expected by mds/Spotlight to work correctly.

 

 

vnap_getattr. It also demands va_linkid to be a unique value for each link target (they all share the same va_fileid, but each one has its own va_linkid). And this va_linkid is used

 

For hardlinks, we then build two AVL trees, zfsvfs->z_hardlinks and zfsvfs->z_hardlinks_linkid in vnop_getattr. The first AVL is indexed by (parent id, file id, name) and the latter by (linkid). This allows us to create new

and unique va_linkid for hardlinks when we come across them (starting at 0x80000000 due to 32bitness, in a weak attempt to avoid collisions). vfs_vget() then checks the AVL tree for va_linkid and if found, can zget the correct

va_fileid, and set the hardlink name and parent id. If the AVL does not contain the va_linkid, it falls back to regular va_fileid lookup. So even if there are collisions, it should be able to cope.

 

Care is also needed in vnop_remove, to clean out the hardlink AVL node in both trees, as well as in vnop_rename, to update the new source mapping (parent id, file id, name).  The AVL trees are unloaded at unmount.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

[[zfs.exports]]