torture: trickfs #765
torture: trickfs #765
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
pepyakin
changed the base branch from
graphite-base/765
to
pep-ci-install-fuse
pepyakin
force-pushed
the
pep-ci-install-fuse
branch
from
69f9ed1 to
c1e1c91
Compare
trickfs/src/lib.rs
Outdated
| // | ||
| // One safety note here is that `ptr` is allocated with `MAP_NORESERVE` flag, so | ||
| // the memory is only "committed" upon the first access and if there is not actual | ||
| // physical memory to back it up, the kernel will kill the process. |
There was a problem hiding this comment.
Does this mean that even if we are mmapping the entirety of the file, the os will allocate only a portion of the physical memory only at the time it is being written, right?
There was a problem hiding this comment.
Yeah, essentially.
But I think the documentation sucks here, it is a lazy explaination: memory mapped regions start their life unbacked by phyiscal pages either way and only get backed by one upon the first access.
However, by default the system reserves the swap space for the mapping and we are doing here 1 TiB, which is too much!
| return; | ||
| }; | ||
| // TODO: this is definitely wrong wrt sign ext. | ||
| let offset = offset as usize; |
There was a problem hiding this comment.
I see how it could be wrong with a negative offset, but I don't really see why the offset is an i64. Is it to support a Seek mode?
There was a problem hiding this comment.
I am not sure why would it be this way. Probably some idiosynchronies of unix. I don't think this is seek because that, I would imagine, should be handled on another level.
The comment is wrong, it seems like I assumed that the offset is i32. No sign extension should happen here.
| panic!("container entry is not registered") | ||
| } | ||
| Some(inode_data) if inode_data.is_dir() => { | ||
| panic!("unexpected nested directory"); |
There was a problem hiding this comment.
Why there can't be nested directories? It doesn't seem to be not permitted on creation, but the opposite, mkdir requires the parent to be a directory.
The weird thing is that the following test passes. Does fuse handle recursive dir deletion on its own?
#[test]
fn rmdir() {
init_log();
let mountpoint = tempfile::tempdir().unwrap();
let options = &[
MountOption::RW,
MountOption::AutoUnmount,
MountOption::FSName("trick".to_string()),
];
let fs = Trick::new();
let mount_handle = fuser::spawn_mount2(fs, &mountpoint, options).unwrap();
let dirname1 = mountpoint.path().join("dir_to_remove");
let dirname2 = dirname1.clone().join("dir_within_dir");
let _ = fs::create_dir(&dirname1).unwrap();
let _ = fs::create_dir(&dirname2).unwrap();
assert!(dirname1.clone().exists());
assert!(dirname2.clone().exists());
fs::remove_dir_all(&dirname1).unwrap();
assert!(!dirname1.exists());
assert!(!dirname2.exists());
drop(mount_handle);
}There was a problem hiding this comment.
oh yeah, it's not fuse though: I think this is the contract between VFS & FS!
pepyakin
changed the base branch from
pep-ci-install-fuse
to
graphite-base/765
pepyakin
force-pushed
the
graphite-base/765
branch
from
c1e1c91 to
6ff0f15
Compare
Introduces trickfs, a fuse filesystem for made for failure injection.
Introduces trickfs, a fuse filesystem for made for failure injection.