mirror of
https://github.com/seaweedfs/seaweedfs.git
synced 2026-09-14 02:20:41 +02:00
* benchmark tool for mounted filesystems * ci: on-demand mount benchmark, native WinFsp vs rclone plus a Linux reference * windows mount: let the Windows cache manager cache file data WinFsp only turns the cache manager on for a file when FileInfoTimeout is infinite; at any finite value every application read and write is a synchronous trip into the mount process at whatever size the application issued. Metadata events already reach FspFileSystemNotify, which purges a changed file's cached pages and attributes, so an infinite timeout stays coherent. The dir listing, volume info and EA timeouts are pinned to one second so they do not silently inherit the infinity. * windows mount: cache resolved paths and attributes in the adapter WinFsp addresses every operation by path and has no FORGET, so the adapter walked the whole path through Lookup on each one, and in a directory the filer has not listed yet every walk was a filer round trip; nothing played the part of the kernel's dentry and attribute caches. The path cache owns one lookup reference per entry the way the kernel holds one until FORGET, serves attribute reads for files without an open handle, and is purged by the mount's own mutations and by metadata events, with the timeout as backstop. * windows mount: keep a closed file's attributes cached Open steals the path's cache entry for its handle and Release returned the reference with a purge, so the stat that follows every copied file walked to the filer again. Reading the handle's final attributes before it goes away and moving the reference back into the cache serves that stat locally, the way the kernel's attribute cache does after a close. Only if the path still names that inode, though: WinFsp reports the path the handle opened with, and after a delete-on-close or a rename caching it would resurrect an entry that is gone. * windows mount: persist entries at create, and let the flush stay at close WinFsp posts the cleanup and close that carry the flush after CloseHandle has returned, so deferring the filer entry to the flush let everything that reads through the filer race an unflushed close: a listing missed just-written files, and a directory rename moved a directory on the filer before its newest child existed there, leaving the straggler flush to recreate the child under the dead path. Flush-at-cleanup is not the answer either: it makes every handle's cleanup flush, and those flushes race the unlinks of delete-on-close, re-inserting the entry the unlink just removed. Persisting the entry at create takes the ordering question away. * mount: flush written pages before a truncate shrinks past them The shrink trims chunks, but written pages that have not become chunks yet are invisible to it, so the next flush wrote them back and the file grew again, resurrecting the truncated bytes. Windows hits this on every write-then-shrink because its flush runs after CloseHandle, but the gap is platform-neutral. * mount: order a file's unlink against its in-flight flush Unlink set the handle's deleted flag bare, so a flush already past its own check of that flag wrote the entry back right after the delete removed it, and a delete-on-close file outlived its last handle. The flag is now set under the handle's flush lock and re-checked under it, so a flush either completes before the delete or sees the flag and skips. An eagerly created handle also starts clean: the dirty mark existed to make the deferred filer create happen at flush, and eager creates have nothing to flush.
64 lines
2.3 KiB
Go
64 lines
2.3 KiB
Go
package winfsp
|
|
|
|
import (
|
|
cgofuse "github.com/winfsp/cgofuse/fuse"
|
|
|
|
"github.com/seaweedfs/seaweedfs/weed/glog"
|
|
"github.com/seaweedfs/seaweedfs/weed/mount/meta_cache"
|
|
"github.com/seaweedfs/seaweedfs/weed/util"
|
|
)
|
|
|
|
// notifier turns the mount's metadata events into the notifications Windows
|
|
// listens for. Nothing invalidates a Windows client's cache from this side, so
|
|
// without it a change made by another mount, the S3 gateway or the filer API
|
|
// stays invisible until the user refreshes by hand.
|
|
type notifier struct {
|
|
host *cgofuse.FileSystemHost
|
|
fs *WinFS
|
|
mountRoot util.FullPath
|
|
}
|
|
|
|
// notify reports one applied event. Windows wants the path relative to the
|
|
// mount, and an action describing what happened to it; the adapter's own path
|
|
// cache is out of date for the same path.
|
|
func (n *notifier) notify(invalidation meta_cache.EntryInvalidation) {
|
|
if n.host == nil {
|
|
return
|
|
}
|
|
// A rename arrives as two invalidations, one vacating the old path and one
|
|
// describing the new, so reporting RenamedTo here as well would send the
|
|
// destination twice — and as a create even when a directory moved.
|
|
if path, ok := relativeToMount(n.mountRoot, invalidation.Path); ok {
|
|
isDirectory := invalidation.WasDirectory || invalidation.Entry.GetIsDirectory()
|
|
n.fs.invalidatePath(path, isDirectory)
|
|
n.send(path, n.action(invalidation))
|
|
}
|
|
}
|
|
|
|
func (n *notifier) send(path string, action uint32) {
|
|
if !n.host.Notify(path, action) {
|
|
// A rejected notification only costs a stale view until the client
|
|
// looks again, so it is not worth failing an operation over.
|
|
glog.V(4).Infof("winfsp notify %s action %d rejected", path, action)
|
|
}
|
|
}
|
|
|
|
// action picks what to tell Windows happened. It cannot distinguish a created
|
|
// entry from a modified one, and Windows treats an unexpected create on an
|
|
// existing name as a refresh, so create is the safe report.
|
|
func (n *notifier) action(invalidation meta_cache.EntryInvalidation) uint32 {
|
|
if invalidation.Deleted || invalidation.Entry == nil {
|
|
// The entry is gone, so only WasDirectory still says what it was, and
|
|
// Windows watches directory and file removals through different
|
|
// filters.
|
|
if invalidation.WasDirectory {
|
|
return cgofuse.NOTIFY_RMDIR
|
|
}
|
|
return cgofuse.NOTIFY_UNLINK
|
|
}
|
|
if invalidation.Entry.GetIsDirectory() {
|
|
return cgofuse.NOTIFY_MKDIR
|
|
}
|
|
return cgofuse.NOTIFY_CREATE
|
|
}
|