Re: [Chicken-users] Curious about limitations of fuse egg, can't open a fossil on the hashfs example fuse fs.
Oh, I should also point out that if you install the egg with `chicken-install -D fuse-debug ...`, it will log filesystem requests as the server receives them (to stderr, IIRC). Might be useful as a quick way to see what's going on without breaking out the heavy tools. HTH, Evan ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Curious about limitations of fuse egg, can't open a fossil on the hashfs example fuse fs.
Hi Matt, Interesting, cool project. Here are a few guesses at your questions, without having had a look at the specific steps to reproduce. On 2016-09-19 22:24, Matt Welland wrote: > 1. Can't open a fossil on hashfs: I'd bet this is caused by SQLite trying to lock a file with flock(2), which isn't implemented by hashfs.scm or, for that matter, by the egg itself. I'd like to add support for flock callbacks at some point, but even then you'd still need to extend hashfs.scm to do something meaningful with that callback in order to get Fossil to work (assuming I'm right about the underlying issue, that is...). > 3. du -sh returns zero even for a non-empty directory. There's a longstanding TODO in the egg relating to explicit blocksize handling, and I'd bet money this is down to that. In short, the egg only bothers to fill the st_size field of stat structs, leaving st_blksize empty since there isn't really a block size associated with a synthetic filesystem anyway. Usually this is fine since the size in bytes is already provided and most tools will just use that (or assume 512 as the block size, in some cases), but it might be that du(1) is taking that empty field at face value and reporting odd sizes as a result. On Linux, you can get du(1) to report the "real" size of a file (i.e. in bytes, not blocks) with `du -b`, so in your example `du -bsh` *should* report nonzero values for nonempty directories, unless there's something else going on. > 2. On hashfs Megatest compile gets through making the .o files but fails to > link with an error: This might be similar to #3. I may have a go at fixing that TODO soon, and if I do I'll let you know -- I'd be curious to see if that is indeed the cause. Cheers, Evan ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Curious about limitations of fuse egg, can't open a fossil on the hashfs example fuse fs.
I recently upgraded my moosefs install and now have issues compiling my
Chicken based project "Megatest" on moosefs. I've asked for help on the
moosefs email list but this got me thinking, what could my compilation of
Megatest possibly be doing that pushes the filesystem? So I thought I'd try
on some other fuse based filesystems and what better than try the fuse
chicken egg. Amazingly it *almost* works!
Results so far (using hashfs.scm from the fuse egg examples directory):
1. Can't open a fossil on hashfs:
matt@mars:~/data/testhashfs/delme$ fossil open ~/fossils/megatest.fossil
SQLITE_NOTADB: statement aborts at 5: [ATTACH DATABASE
'/home/matt/data/testhashfs/delme/.fslckout' AS 'localdb'] file is
encrypted or is not a database
fossil: file is encrypted or is not a database: {ATTACH DATABASE
'/home/matt/data/testhashfs/delme/.fslckout' AS 'localdb'}
2. On hashfs Megatest compile gets through making the .o files but fails to
link with an error:
matt@mars:~/data/testhashfs/megatest$ make
csc common.o items.o launch.o ods.o runconfig.o server.o configf.o db.o
keys.o margs.o megatest-version.o process.o runs.o tasks.o tests.o
genexample.o http-transport.o nmsg-transport.o filedb.o client.o synchash.o
daemon.o mt.o ezsteps.o lock-queue.o sdb.o rmt.o api.o tdb.o
rpc-transport.o portlogger.o archive.o env.o megatest.o -o mtest
/usr/bin/ld: error: common.o: file too short
collect2: error: ld returned 1 exit status
3. du -sh returns zero even for a non-empty directory.
This email is not a bug report and I'm not asking for any of these to be
"fixed" as hashfs.scm is just an example but the short file from compiling
common.scm seems interesting and perhaps is related to the moosefs issue.
Anyone have suggestions on things to look for in a source file that might
be challenging for a filesystem? For the record, both fossil open and
building/running Megatest work fine on sshfs, another fuse based filesystem.
I pasted the instructions I gave to the Moosefs folks for reproducing the
problem below in case it is useful.
Thanks,
Matt
-=-
How to reproduce:
1. Install chicken + IUP gui (alternative: use Makefile.installall from
utils dir in Megatest)
wget http://www.kiatoa.com/matt/chicken_4.11rc2_x86.tar.gz
/tmp/chicken.tar.gz
cd /opt;tar xf /tmp/chicken.tar.gz
source /opt/chicken/4.11rc2_x86_64/setup-chicken4x.sh
2. Get Megatest source for v1.61 (project is at https://www.kiatoa.com/
fossils/megatest)
wget http://www.kiatoa.com/matt/megatest_v1.61_src.tar.gz
/tmp/megatest.tar.gz
tar xf /tmp/megatest.tar.gz
cd megatest
make clean;make -j && make install
cd tests
source fixpath.sh
make dashboard
== results ==
cd fullrun && /mfs/tmp/megatest/bin/dashboard -skip-version-check -rows 20 &
matt@xena:/mfs/tmp/megatest/tests$
Error: segmentation violation
Call history:
dcommon.scm:68: hash-table-set!
tree.scm:12: ##sys#require
tree.scm:13: ##sys#require
tree.scm:15: ##sys#require
tree.scm:17: ##sys#require
tree.scm:17: ##sys#require
tree.scm:17: ##sys#require
altdb.scm:2: make-hash-table
altdb.scm:3: ##sys#require
altdb.scm:3: hash-table-set!
vg.scm:13: ##sys#require
vg.scm:16: ##sys#require
vg.scm:16: ##sys#require
vg_records.scm:4: ##sys#require
vg_records.scm:5: make-exception
vg_records.scm:17: ##sys#require <--
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
