Re: CVS commit: src/sys/fs/puffs
hi, > YAMAMOTO Takashi wrote: > >> if it trapped forever, it's a bug and should be fixed. my point was >> that your change didn't fix the bug. blocking ioflush is merely a symptom. > > The problem with userland filesystems is that we may have little control > as theses may be third pary programs. Should kernel threads trust theses > processes in order to run as intended? i guess it depends. is ioflush blocking forever worse than a userland application blocking forever? it depends. even if it's a problem, it isn't a problem specific to userland filesystems. filesystems have varying performance and reliability. > > One way to fix that may be to have one ioflush thread for each userland > filesystem. That way a broken filesystem will not prevent ioflush from > working for others. But we have hit similar problems with others kernel > threads. sure, it can be a good idea. YAMAMOTO Takashi > > -- > Emmanuel Dreyfus > http://hcpnet.free.fr/pubz > m...@netbsd.org
Re: CVS commit: src/sys/fs/puffs
YAMAMOTO Takashi wrote: > if it trapped forever, it's a bug and should be fixed. my point was > that your change didn't fix the bug. blocking ioflush is merely a symptom. The problem with userland filesystems is that we may have little control as theses may be third pary programs. Should kernel threads trust theses processes in order to run as intended? One way to fix that may be to have one ioflush thread for each userland filesystem. That way a broken filesystem will not prevent ioflush from working for others. But we have hit similar problems with others kernel threads. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: CVS commit: src/sys/fs/puffs
hi, > YAMAMOTO Takashi wrote: > >> > Sure ioflush do not directly free memory, but vnodes' dirty page use >> > memory, don't they? If ioflush stops working, is pageadaemon able to >> > pageout that kind of memory? >> pagedaemon flushes dirty pages by itself, yes. > > So this is not a problem to get ioflush traped forever awaiting for a > VOP_FSYNC completion? There must be some drawback, otherwise ioflush > would be useless. if it trapped forever, it's a bug and should be fixed. my point was that your change didn't fix the bug. blocking ioflush is merely a symptom. on the other hand, it needlessly introduced a limitation on what kernel threads can do. now we have vdrain_thread which i think can hit the LW_SYSTEM assertion in puffs_vnop_fsync. > >> a possible solution would be local page recycling. ie. reserve some pages >> and put them onto a page queue dedicated for a given set of processes >> so that pages can be recycled in the set independently from the global queue. > > But we do not know how much memory the userland fileserver is going to > require. We can have some reserves, but we must be ready to kill pigs if > too much memory is retained by the fileserver. HEAD does it, but > netbsd-5 prefers to hang. you don't need to know how much memory the server will use. when the server runs out of the reserved set of pages, you can reuse pages in the set. YAMAMOTO Takashi > > -- > Emmanuel Dreyfus > http://hcpnet.free.fr/pubz > m...@netbsd.org
Re: CVS commit: src/sys/ufs/ufs
On Tue, Oct 11, 2011 at 04:40:02AM +, David Holland wrote: > On Sun, Oct 09, 2011 at 09:15:34PM +, Chuck Silvers wrote: > > Modified Files: > >src/sys/ufs/ufs: extattr.h > > > > Log Message: > > add forward declarations for the VOP args structures > > so that fstat can include this file. > > Do we really want fstat using fs-specific headers and interfaces? > > (I know, cleaning it up is probably nontrivial) sure, it'd be better if fstat used sysctl instead of libkvm to extract all this info from the kernel, but as you say, non-trivial. -Chuck
