On Wed, 2007-09-05 at 18:24 +0100, Frank Hofmann wrote: > On Wed, 5 Sep 2007, Kaiwai Gardiner wrote: > > > On Tue, 2007-09-04 at 13:46 -0700, Fintan Ryan wrote: > >> Hi Folks, > >> > >> This is great to see, I was playing with the binaries that were > >> available from August 14th a few days ago in order a new iPod nano, > >> one question though - is the code in the webrev substantially > >> different from the code base that the binaries from Aug 14th were > >> built from? If so would it be possible to get the updated binaries > >> posted as well? > >> > >> - Fintan > > > > Just a follow up to that, does it address long standing performance > > issues with the pcfs design. > > Nope, this doesn't attempt to solve that yet. > The biggest performance inhibitor is the singlethreadedness, 4293035. > > > A rough design sketch how to get rid of that would look like this: > > Locks needed in "struct pcfs": > > - a 'pcfs_instancelock' to do the forced umount synchronisation in the > PCFS_ENTER() / PCFS_EXIT() style (as ZFS does) > * every op does the enter/exit protocol > > - a 'pcfs_renamelock' to synchronize between vnode ops that require > updates to directory structure (create, rename, remove of files/dirs) > and all other vnodeops > * every op that requires vnode persistence does RW_READER > * every op that does directory modification does RW_WRITER > > - a 'pcfs_fatlock' (possibly in a rangelock style to allow parallelism) > to synchronize updating the FAT on alloc/free > * FAT reads (pc_getcluster, pc_freeclusters - or their callers) > do RW_READER > * FAT writes (pc_setcluster, pc_alloccluster - or their callers) > do RW_WRITER > > - a 'pc_nodelock' for the file nodes > * RW_READER for things that do not modify more than atime > * RW_WRITER for modifications to the file size/contents > * atomic ops for pc_flags > > renamelock and the nodelock should be modeled after the nfs reentrant-safe > / interruptible shared-exclusive locks, since they'll be held over > duration of a vnode op (and those can recurse - infamous write/read => > getpage/putpage problem, and layering such as via sendfile and/or NFS). > > That should allow a reasonable amount of concurrency, while at the same > time avoiding typical deadlock scenarios. > > For the above outlined simplicity of locking, we would, in the initial > delivery, still singlethread: > > - writes (only one writer per file) > - directory updates of any sort (create/delete/rename will > block all other operation on the filesystem) > > So this is sketched out roughly, but no coding has started on this yet > (and, given my commitments changed, isn't going to start by myself any > time soon either).
Cool but in regards to how the FAT is read, that is, dumping the whole thing in memory rather than a gradual read - is that going to be a addressed soon? > > Also, is there an eta on when FATex will supported? > > What's FATex ? Oops, I meant exFAT: http://en.wikipedia.org/wiki/ExFAT Matthew _______________________________________________ opensolaris-discuss mailing list [email protected]
