So, I don’t know what I’m doing atm… what I see is that types requires sudo, which is unfortunate; and regardless the fs type suggested, it gives the same error… also, I wonder it does make sense, as surely the drive being mounted is expected to have a known format; and it’s unclear if there’s deliberate intent to emulate one standard type.
So, atm I get
$ sudo mount -t vfat ./sn_fs /media/safe/test
mount: /media/safe/test: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error.
but I don’t know enough to make sense of mount command.
I note oddly different help result from mount --help and more useful perhaps is man mount detail which tempts mount [-fnrsvw] [-t fstype] [-o options] device dir
I suppose as @jlpell suggests fuse can throw glitches but unclear what fs type we’re mounting here and if the sn_fs is setup to match what mount might be wanting…
Apologies for the slow response, not getting the time I want to do SAFE stuff these days…
Your mount type should be fuse as in mount -t fuse <blah>
Heres what I have…
willie@gagarin:~/projects/maidsafe/sn_fs/sn_fs_test_area/local_sites/testArea$ mount |grep safe
sn_fs on /home/willie/projects/maidsafe/sn_fs/sn_fs_test_area type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
but I did not issue an explicit mount command - I simply did as below
w illie@gagarin:~/projects/maidsafe/sn_fs$ RUSTLOG=debug cargo run sn_fs_test_area/
Finished dev [unoptimized + debuginfo] target(s) in 0.03s
Running target/debug/sn_fs sn_fs_test_area/
Tree works exactly as expected but when I do an ls - the dir sizes all seem to be zero
so, mount -t fuse works and perhaps that’s a step forward but ./sn_fs doesn’t seem to behave like a device for this to work: sudo mount -t fuse ./sn_fs /media/safe/test
that makes the /test location look like a file and likely is ./sn_fs mounted as a file.
willie@gagarin:~/projects/maidsafe/sn_fs$ mount |grep safe
sn_fs on /home/willie/projects/maidsafe/sn_fs/sn_fs_test_area type fuse (rw,nosuid,nodev,relatime,user_id=0,group_id=0)
now what running tweaks have I made over the last few weeks so that this rather old kludgy system comes back up nicely? I know my screens will be in the wrong order – 3 monitors is great when the are working right but I had to replace a 1920x1080 with a 1600x900 until I get ££ in for a proper replacement…
I’m not sure mount makes sense for a filesystem that doesn’t already exist.
So ./sn_fs works but for that exec flag oddity… but it’s not clear that it maps to a known file system type. Once ./sn_fs is running perhaps then it could be mounted as a device but it automounts to its location and mounting again makes no useful difference… beyond what a sym link would do.
mount is for /dev/ as devices?.. ./sn_fs is not a device but a route to locating the filesystem it creates?.. thinking it’s not one we can solve unless the intent is that ./sn_fs is a device… confused atm.
Yes I think I agree with that.
cargo run (when run in the sn_fs dir) both creates and mounts the file system. Seems like when we try to use mount we are trying to attach a non-existent device to a mountpoint. So all talk o sudo and what type should follow -t is meaningless.
enough of this - in further homage to the happy being who has inspired much of this I am going to relax by getting this flawless. This may take some time to get close to this class , let alone approaching how Mick does it.
yes, sn_fs presently reports dir sizes as zero. Ext2/3/4 reports 4096, which is the minimum block size. Anyway, that is up to the individual fs, and should not affect functionality at all. Perhaps a more “correct” thing to do would be to report the exact number of bytes that comprise the directory inode.
It doesn’t make sense that only root can access a fuse mount. Looking through the answers it looks like you can control access with the options although I haven’t tried anything out.
I think being able to use fstab can be a handy way of setting up a system so the user has a simple mount command, but the fstab entry has the config.
yes, I believe you can, eg with the allow_other option to fuse. However, that option must be provided to fuse by sn_fs, which currently is not accepting options from cli args. Also allow_other requires user_allow_other be set in /etc/fuse.conf. There may be some easier/better way… These sorts of fine points I haven’t really focused on yet for PoC.
for a production filesystem, sure. For a proof-of-concept proving that a tree crdt can represent directories, symlinks, hardlinks, etc. not really.
df and df -i are fine points and will be addressed assuming we move forward with this approach. Thx for bringing it to my attention, and if you are able, please file an issue about it.
The real problems to solve though will be about integrating with the network, storing/fetching files, caching, os independent ownership and permissions, and achieving adequate performance over live network all in a secure fashion.
I think things like df and df -i and possibly directory sizes are going to be easy to get working because @danda has done an amazing job of getting the underlying CRDT structures to work very closely to how regular Linux filesystems operate.
So I guess for now the focus is on the bigger question he poses as to whether this approach should be taken forward, based on how well it can work as a general purpose decentralised filesystem.
I’m not sure if that’s something we can know until we get back to test networks, but maybe there’s some preparation that could be done. For example, thinking what we’d like to use sn_fs for, and planning how to test it on our individual use cases. I have a few tests I used on the old Safe Drive, so I’ll dig those out.
I haven’t played yet, but am really impressed with what I’ve seen posted. Well done @danda and MaidSafe, fingers crossed it all pans out because this could be a major advantage over other projects.
