Skip to content

Commit 8fc09b8

Browse files
committed
improve file delete performance
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
1 parent 7d791d2 commit 8fc09b8

1 file changed

Lines changed: 11 additions & 7 deletions

File tree

fuseutil/file_system.go

Lines changed: 11 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -84,13 +84,15 @@ type FileSystem interface {
8484
// requests").
8585
func NewFileSystemServer(fs FileSystem) fuse.Server {
8686
return &fileSystemServer{
87-
fs: fs,
87+
fs: fs,
88+
opsForgetInode: make(chan int, 100000),
8889
}
8990
}
9091

9192
type fileSystemServer struct {
92-
fs FileSystem
93-
opsInFlight sync.WaitGroup
93+
fs FileSystem
94+
opsInFlight sync.WaitGroup
95+
opsForgetInode chan int
9496
}
9597

9698
func (s *fileSystemServer) ServeOps(c *fuse.Connection) {
@@ -113,11 +115,12 @@ func (s *fileSystemServer) ServeOps(c *fuse.Connection) {
113115

114116
s.opsInFlight.Add(1)
115117
if _, ok := op.(*fuseops.ForgetInodeOp); ok {
116-
// Special case: call in this goroutine for
117118
// forget inode ops, which may come in a
118-
// flurry from the kernel and are generally
119-
// cheap for the file system to handle
120-
s.handleOp(c, ctx, op)
119+
// flurry from the kernel and we should
120+
// to limit the number of goroutines
121+
// one goroutine 2KB, 10w goroutine max 200MB
122+
s.opsForgetInode <- 1
123+
go s.handleOp(c, ctx, op)
121124
} else {
122125
go s.handleOp(c, ctx, op)
123126
}
@@ -150,6 +153,7 @@ func (s *fileSystemServer) handleOp(
150153

151154
case *fuseops.ForgetInodeOp:
152155
err = s.fs.ForgetInode(ctx, typed)
156+
<-s.opsForgetInode
153157

154158
case *fuseops.MkDirOp:
155159
err = s.fs.MkDir(ctx, typed)

0 commit comments

Comments
 (0)