From 4b07f0de3efee5e7a4ef8ead84825bf065f28361 Mon Sep 17 00:00:00 2001 From: kungf Date: Tue, 17 Mar 2020 11:30:46 +0800 Subject: [PATCH] use as many goroutines for ForgetInode op in #30 forgetinode was changed into inline ServerOps, this may solove memory oom, but the performance of rm op will be very slow, and it will also hang other ops, so i think limit the max num of forgetinode goroutines, this can avoid oom but not affect performance --- fuseutil/file_system.go | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/fuseutil/file_system.go b/fuseutil/file_system.go index 5eb8bcaa..7836c53a 100644 --- a/fuseutil/file_system.go +++ b/fuseutil/file_system.go @@ -84,13 +84,15 @@ type FileSystem interface { // requests"). func NewFileSystemServer(fs FileSystem) fuse.Server { return &fileSystemServer{ - fs: fs, + fs: fs, + opsForgetInode: make(chan int, 100000), } } type fileSystemServer struct { - fs FileSystem - opsInFlight sync.WaitGroup + fs FileSystem + opsInFlight sync.WaitGroup + opsForgetInode chan int } func (s *fileSystemServer) ServeOps(c *fuse.Connection) { @@ -113,11 +115,12 @@ func (s *fileSystemServer) ServeOps(c *fuse.Connection) { s.opsInFlight.Add(1) if _, ok := op.(*fuseops.ForgetInodeOp); ok { - // Special case: call in this goroutine for // forget inode ops, which may come in a - // flurry from the kernel and are generally - // cheap for the file system to handle - s.handleOp(c, ctx, op) + // flurry from the kernel and we should + // to limit the number of goroutines + // one goroutine 2KB, 10w goroutine max 200MB + s.opsForgetInode <- 1 + go s.handleOp(c, ctx, op) } else { go s.handleOp(c, ctx, op) } @@ -150,6 +153,7 @@ func (s *fileSystemServer) handleOp( case *fuseops.ForgetInodeOp: err = s.fs.ForgetInode(ctx, typed) + <-s.opsForgetInode case *fuseops.MkDirOp: err = s.fs.MkDir(ctx, typed)