On Oct 22, 2007, at 4:20 PM, Amit Singh wrote:
> > >> 1) The disk icon is incorrect, and eject messages are not sent to the >> disk drive when the volume is ejected. How do I indicate to MacFuse >> that the volume is associated with a particular disk device? > > Incorrect how? What should it be? Do you have a custom volume icon > that you want to show up on the Desktop? If so, you should look into > the 'volicon' mount-time option. > > MacFUSE doesn't care where your /actual/ backing storage is--that's > entirely up to the user-space program implementing the file system. > Sounds like one option you have would be to implement the destroy > method in your file system and cause it to eject the physical disc. > Since the backing store for the FS is an actual /dev/disk, I'd like it to show the volume icon provided by the device driver, in the same way that the HFS file system does. Implementing the destroy method in the FS to eject the physical disc should work, but I know that the association between a file system and it's device vnode is normally maintained by the OS, and I'd like to come up with a way to use the existing mechanism, if possible. I guess I have some research to do in order to determine how that mechanism currently works. >> 2) The volume cannot be renamed. Is there a way to support this? > > The FUSE API has no concept of volume names (and hence volume > renaming). Even though MacFUSE has numerous things that are different > from, or in addition to what the Linux implementation has, volume > renaming is not one of them. Looks like I'm going to be needing to add that, then. How adverse are you to adding Mac specific APIs? > >> 3) Cluster mapped I/O is not supported. Will implementing bmap >> resolve this? Is there a sample anywhere which implements bmap? > > MacFUSE doesn't support bmap. On Linux, bmap is an inode-level > operation that the Linux vfs calls to map a logical block offset to a > physical block number. It's used (or was used the last I saw) by the > swapper on Linux, but its use is deprecated there. What exactly do you > mean by "not supported"? What's your use case that you want to work? I was hoping that bmap might be a way to achieve some support for the unified buffer cache, at a per file level. Currently the best that can be hoped for is that the UBC will associate all of the files on the volume with a single vnode (the device's vnode). MacOS (as of 10.4) uses the "blockmap" function to allow files to be memory mapped, and to support cluster mapped I/O. Within the blockmap function, a file system describes a file's extents in terms of blocks, allowing the operating system to bypass the "read" and "write" codepaths within the file system, and perform the I/O itself using the unified buffer cache. Of course, this only works if the file's contents are stored on a block device, and are block aligned. At any rate, I don't think that bmap is a good fit, as it seems to have been written to provide a mapping between a single block in the file and a single block on disk, rather than an extent within a file, and an extent on disk. >> 4) Named attributes are not supported (setxattr, etc...). Are these >> methods used under Mac OS X 10.4? > > Not supported where/how? Both Mac OS X (yes, including 10.4) and > MacFUSE support extended attributes (setxattr, etc.). > That's what I needed to know - I haven't implemented them yet within UDF, and need to figure out how they fit. As I recall, there is some connection between resource forks and extended attributes under 10.5? Does that imply that the size parameter in setxattr can be very large? > Amit Again, thanks for your time, Ron Aldrich Software Architects, Inc. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "macfuse-devel" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/macfuse-devel?hl=en -~----------~----~----~----~------~----~------~--~---
