Apple

can you get a full sysdiagnose when it is in this state

George

On Jun 19, 2014, at 11:26 AM, Vadim Galitsyn <email@hidden> wrote:

Alexander, George,

Thank you for your hints!

“lsof” shows the same before and after attempt to unmount volume. It states that Finder (and no other process) is using the parent directory of the mount point (volume mounted to /Users/test/vfs_plugin/mnt):

Finder 198 test 11r DIR 1,2 1428 842924 /Users/test/vfs_plugin

“diskutil unmount” also fails to unmount the volume (also freezes, but once I saw it reported an error after some timeout and released console). Unmount operation also unable to complete in attempt to eject volume from Finder.

“spindump” clarified situation a bit. It showed that one of the Finder’s threads is waiting for vfs_busy() in kernel. According to comment within vfs_busy(), it is waiting for dounmount() to release the lock. However, dounmount() is waiting for something else and never release it. Here is the backtrace for Finder thread:

Thread 0x9e7 DispatchQueue 556 priority 46
1001 start_wqthread + 13 (libsystem_c.dylib) [0x7fff8b8331d1]
1001 _pthread_wqthread + 404 (libsystem_c.dylib) [0x7fff8b848d0b]

1001 _dispatch_worker_thread2 + 249 (libdispatch.dylib) [0x7fff8ad951c3]
1001 _dispatch_queue_invoke + 52 (libdispatch.dylib) [0x7fff8ad952f1]
1001 _dispatch_queue_drain + 235 (libdispatch.dylib) [0x7fff8ad9547f]

1001 _dispatch_client_callout + 8 (libdispatch.dylib) [0x7fff8ad940b6]
1001 _dispatch_call_block_and_release + 15 (libdispatch.dylib) [0x7fff8ad97f01]
1001 __PostNodeTaskRequest_block_invoke_0 + 91 (DesktopServicesPriv) [0x7fff9358fbe1]

1001 ExceptionSafeBlock(void ()() block_pointer) + 12 (DesktopServicesPriv) [0x7fff9358fc40]
1001 __block_global_1 + 82 (DesktopServicesPriv) [0x7fff9360313f]
1001 TNode::HandleNodeRequest(TCountedPtr<TNodeTask> const&, TCountedPtr<TVolumeSyncThread> const&) + 757 (DesktopServicesPriv) [0x7fff9358ff8b]
1001 TNode::HandleSync(TCountedPtr<TNodeTask> const&, TNodePtr const&) + 42 (DesktopServicesPriv) [0x7fff935b3988]

1001 TNode::HandleSync(unsigned int) + 502 (DesktopServicesPriv) [0x7fff9359f972]
1001 TFSInfo::Initialize(__CFURL const*) + 254 (DesktopServicesPriv) [0x7fff9358a0aa]

1001 TFSInfo::FetchProperties() + 213 (DesktopServicesPriv) [0x7fff9358a1f7]
1001 _CFURLCopyResourcePropertyValuesAndFlags + 191 (CoreFoundation) [0x7fff8dc6995f]

1001 _FSURLCopyResourcePropertyValuesAndFlags + 584 (CoreServicesInternal) [0x7fff8f9f6905]
1001 prepareValuesForBitmap(__CFURL const*, __FileCache*, _FilePropertyBitmap*, __CFError**) + 216 (CoreServicesInternal) [0x7fff8f9f5397]

1001 __getattrlist + 10 (libsystem_kernel.dylib) [0x7fff94f62bd2]
*1001 hndl_unix_scall64 + 19 (mach_kernel) [0xffffff80002ce9c3]

*1001 unix_syscall64 + 522 (mach_kernel) [0xffffff80005e16aa]
*1001 getattrlist + 144 (mach_kernel) [0xffffff80002d9a60]

*1001 namei + 1454 (mach_kernel) [0xffffff80002eae1e]
*1001 lookup + 854 (mach_kernel) [0xffffff80002eb566]
*1001 lookup_handle_found_vnode + 195 (mach_kernel) [0xffffff80002eafb3]
*1001 lookup_traverse_mountpoints + 226 (mach_kernel) [0xffffff80002ebd92]

*1001 vfs_busy + 187 (mach_kernel) [0xffffff80002ee9bb]
*1001 msleep + 116 (mach_kernel) [0xffffff800056a1c4]

*1001 ??? (mach_kernel + 3579350) [0xffffff8000569dd6]
*1001 lck_mtx_sleep + 78 (mach_kernel) [0xffffff800022664e]

*1001 thread_block_reason + 300 (mach_kernel) [0xffffff800022db8c]
*1001 ??? (mach_kernel + 190657) [0xffffff800022e8c1]

*1001 machine_switch_context + 366 (mach_kernel) [0xffffff80002b47fe]

George, I completely understand you propose to update to Mavericks and will definitely do so. The other thing here is that I would like to make VFS plug-in to work with OS X starting from version 10.6. Btw, I am also forced to use Xcode 3.2.x and OS X SDK 10.6.

Vadim

On 18 Jun 2014, at 20:46, Vadim Galitsyn <email@hidden> wrote:

Thank you, George!

Finally, I was able to make Finder able to browse mount point content. Seems it wanted fsid and absolute path to mount point. However, once I browsed it with Finder, I am no longer able to unmount it. Unmount freeze and this is a deadlock in kernel [dounmount()->vflush()->vnode_reclaim_internal()->vnode_drain(), waiting for vp->v_iocount which is >1]. Therefore, vfs_unmount() callback is never called.

This does not happen if I browsed it with console tools. Even if mount point is busy, vfs_unmount() callback is called and unmount tool receives expected EBUSY.

I have suspicion that once I browsed with Finder, some system service (mds?) starts watching mount point and never release it. The question is how to notify service (if this is the case) about unmount or tell it to do not watch for the mount point.

Btw, once I attempt to kill mds while unmount is stuck, it becomes zombie.

Sorry, I have not specified OS X version which I am experimenting with. It’s 10.8.4 at the moment.

Thank you in advance for any input,
Vadim

On 10 Jun 2014, at 00:28, George K Colley <email@hidden> wrote:

On Jun 9, 2014, at 12:27 PM, Vadim Galitsyn <email@hidden> wrote:

Hi Guys,

Thank you for the answers and apology for delay from my side.

I tried to debug the issue with fs_usage, dtruss and dtrace. It seem that all the callbacks [that Finder expect] are implemented in VFS plug-in and they return correct things.

I tried to get info about a mount point directory using Finder and the next things I got:

Kind: Folder (instead of volume)

Capacity/Available/Used: “Zero bytes” (instead of provided values at VFS plug-in)
Created/Modified: valid time stamp (!)

I attempted to implement a minimalistic command-line tool that behaves in a similar way as Finder and spotted that:

- [Deprecated but still..] FSPathMakeRef(<path to mount point>) fails with rc=-36 (I/O Error);

- CFURLCopyResourcePropertyForKey(<CFURL to mount point>, kCFURLVolumeTotalCapacityKey) returns TRUE while it does not attempt to fill provided CFNumber argument with any value;
- CFURLCopyResourcePropertyForKey(<CFURL to mount point>, kCFURLVolumeSupportsCaseSensitiveNamesKey) returns TRUE and CFBoolean(FALSE) disregarding to actual capabilities value in VFS plug-in;

- It looks like some (all?) CFURLCopyResourcePropertyForKey() results are returned for the root partition instead of the mounted one.

If anyone has ideas what might be a cause of the issue, I would very appreciate any comments!

Just make sure you don't set the volume cap.
Btw, why I should not?
We are trying depreciate that call and its replacement does not require any extra work on your end. In Yosemite Finder will be calling getattrlistbulk which we handle for you.

George

Thank you in advance,
Vadim

On 25 May 2014, at 19:26, George K Colley <email@hidden> wrote:

On May 23, 2014, at 11:38 AM, Alexander Dimitrov <email@hidden> wrote:

Hi Vadim,
Finder is normally reading the content of the volume using the getdirentriesattr(2) which calls the readdirattr callback to the vfs plugin. Is it possible that you are returning an empty buffer on this call?
Have you stated that you support this call in f_capabilities part of vfs_attr, returned by vfs_getattr? If I remember correctly if you don't set its bit Finder should call readdir(like ls(1)) instead of readdirattr and then getattrlist on every entry, which will come as vnode_getattr in your fs.
You could also try running
sudo fs_usage -w Finder
and see what file system calls it makes when you try to open your volume in Finder. The above command will also list return errors in [ ] if any occurs.
Good luck,
Alex
______
The getdirentriesattr call is not required and I would not recommend implementing it. Just make sure you don't set the volume cap. Getting a fs_usage would help, you can do a dtrace call to see what options Finder is requesting on getattrlist.

George
_________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)

This email sent to email@hidden