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

@@ -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)