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).
>
> Also, is there an eta on when FATex will supported?
What's FATex ?
FrankH.
>
> Matthew
>
> _______________________________________________
> opensolaris-discuss mailing list
> [email protected]
>
_______________________________________________
opensolaris-discuss mailing list
[email protected]
