From: Sergey K. <skr...@gm...> - 2010-08-16 13:44:09
|
Hello, all. I'm trying to learn FUSE and have a question: is it normal for FUSE-based system to be notably more slow than "native" FS? Here is an example of proxy-function (I think you all familiar with such ones, they are common in tutorials and examples): -- int proxyfs_mkdir(const char *path, mode_t mode) { char fpath[PATH_MAX]; fullpath(fpath, path); if (mkdir(fpath, mode) < 0) return -errno; return 0; } -- All my functions are like this. Let's test how it works with "time find . | wc -l" on 50000 files. Ubuntu Lucid in Virtual Machine: -- FUSE -- real 0m12.029s user 0m0.024s sys 0m6.272s -- "native" -- real 0m0.350s user 0m0.028s sys 0m0.320s What's wrong? Why? Thank you. Best regards, Sergey Kryzhanovsky. |
From: Goswin v. B. <gos...@we...> - 2010-08-18 12:19:03
|
Sergey Kryzhanovsky <skr...@gm...> writes: > Hello, all. > > I'm trying to learn FUSE and have a question: is it normal for > FUSE-based system to be notably more slow than "native" FS? > Here is an example of proxy-function (I think you all familiar with > such ones, they are common in tutorials and examples): > -- > int proxyfs_mkdir(const char *path, mode_t mode) { > char fpath[PATH_MAX]; > fullpath(fpath, path); > if (mkdir(fpath, mode) < 0) return -errno; > return 0; > } > -- > > All my functions are like this. Let's test how it works with "time > find . | wc -l" on 50000 files. Ubuntu Lucid in Virtual Machine: > -- FUSE -- > real 0m12.029s > user 0m0.024s > sys 0m6.272s > > -- "native" -- > real 0m0.350s > user 0m0.028s > sys 0m0.320s > > What's wrong? Why? > > Thank you. > > Best regards, > Sergey Kryzhanovsky. The problem is that fuse has a fixed overhead for every callback. It needs to switch context from kernel to user and back. And you also switch for the syscall. All of those add a fixed cost to every operation. Now, if you have an operation like readdir and stat (which ls does) the actual time spend on the operation itself is verry small while the fixed overhead is comparatively large. So you get a 6s slowdown. If you had done read/write calls you would still get those 6s slowdown but compared to maybe 60s real work it is much less. Enabling kernel caching for your fuse FS also helps keep the overhead down, at least for the second time you type find. MfG Goswin |