Hello, Per the error - I realized that I am using an older version of S3QL that is distributed in Ubuntu and was installed with its aptitude package manager. I have installed and upgraded to the latest release version (2.18), and will be using it and seeing if I have the same issues. I had just removed the directory structure and re-copied it, with threading turned on per default, and it successfully copied everything (for the first time!) without giving me the transport error. So, we'll see what happens.
Also another question - what is the benefit to changing the maximum file size option during mkfs from the default 10MB? In one case I have particularly larger files on average than 10MB - would I see some kind of benefit by changing this to the average file size? Does this option exist to keep the number of files stored on the fs lower, so as to increase some kind of read speed for the filesystem or something? For instance if I have a lot of large files, in excess of 1GB of each on average, and that is pretty much the only files a particular S3QL filesystem is going to store, should I set that size to 100MB to keep the number of data files low in order to get a performance increase of some kind? Thank you! Brandon On Friday, June 17, 2016 at 4:10:55 PM UTC-5, Nikolaus Rath wrote: > > On Jun 17 2016, Brandon Orwell <[email protected] <javascript:>> wrote: > > I've been using S3QL for a few days now, and whenever I am copying over > > large amounts of data the mount point seems to 'lock up' for a period of > > time (as well as anything else trying to access it), and then I start > > getting 'transport endpoint not connected' errors. I "umount" the mount > > point, run fsck on it. and then continue archiving until the problem > > happens again. > > I've heard this kind of story before, but it still amazes me. What train > of thought led you to this procedure, instead of reporting the problem? > > > Does anyone know what would cause these problems? > > Where did you look for the answer? > > https://bitbucket.org/nikratio/s3ql/wiki/FAQ#!what-does-the-transport-endpoint-not-connected-error-mean > > says: > > ,---- > | What does the "Transport endpoint not connected" error mean? > | > | It means that the file system has crashed. Please check mount.log for a > | more useful error message and report a bug if appropriate. If you can't > | find any errors in mount.log, the mount process may have > | "segfaulted". To confirm this, look for a corresponding message in the > | dmesg output. If the mount process segfaulted, please try to obtain a C > | backtrace (see Providing Debugging Info) of the crash and file a bug > | report. > | > | To make the mountpoint available again (i.e., unmount the crashed file > system), use the fusermount -u command. > | > | Before reporting a bug, please make sure that you're not just using the > | most recent S3QL version, but also the most-recent version of the most > | important dependencies (python-llfuse, python-apsw, python-lzma). > `---- > > > Best, > -Nikolaus > > -- > GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F > Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F > > »Time flies like an arrow, fruit flies like a Banana.« > -- You received this message because you are subscribed to the Google Groups "s3ql" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
