i only just subscribed to the lists, so if either topic has been discussed to death i'd be happy to be referred to a thread... but... that aside here goes: i've been using (playing with at home, and testing as a possible replacement for a large amount of core storage at work) GlusterFS for about a year now... IMHO, it is rapidly approaching the "perfect" solution for a variety of enterprise applications... as even my remote "wishlist" features have been discussed or are already part of the future development path... i've run into two problems... both relatively minor in scope... but both would provide continuous irritation to a user base forced to deal with them 24/7... Problem #1: initial "timeout"/lag-time with auto-mounting... i have added GlusterFS mounts into my AutoFS configuration... (directly modelling after the example on the GlusterFS site) and the result is completely successful, with one single continual irritation... whenever a remote mount is initially requested... instead of actually finishing the request before returning, it seems there is a "long" latency (but probably less than a second) period before the remote filesystem is actually available... and an immediate request for access to a file/dir (i.e. ls(1), or opening a file on an unmounted filesystem directly) will result in (for example): ls: <mountpoint>: Transport endpoint is not connected subsequent requests, however, succeed just fine... and the filesystem remains stable and accessible, until AutoFS unmounts it again due to inactivity... i'm seeking any suggestions to experiment with regarding tuning/minimizing this latency... i've tried endless combinations of varying the options to AutoFS, mount, and glusterfs itself, but nothing has really seemed to improve the situation... Problem #2: this one is strange... i have noticed that OpenOffice (versions 2.0.4 and 2.3.0, at least, on CentOS 4 and 5 respectively) fail to open files on GlusterFS mounts... instead returning the following error: General input/output error while accessing <filename> the reason this is strange... is that other versions of OpenOffice (like 1.1.5 on CentOS 4, and 2.2.1 on SlackWare) don't suffer from this problem at all.. this problem is generally less serious than the first, primarily due to it's limitted scope, but it does reveal that there is something fundamentally different with access to the file via GlusterFS, which can cause access failures... i can't blame FUSE, mount, AutoFS, etc... because i've tested endless other combinations (SSHFS and NTFS over FUSE, for example) and not run into this same error... as above i'm just hoping for some ideas as to what might be going on, and, best case, some suggestions or guidance about overcoming the problem, if possible... anyways... those are my "bug reports"... hopefully, if it's just a matter of "you need to do this" or "your configuration needs this"... that'd be the happiest circumstance... BTW: i am currently running GlusterFS v1.4.0rc7... on systems that have ALL been loaded with "GlusterFS" patched FUSE... the OSes i've been primarily testing with are: CentOS 4 (4.7), CentOS 5 (5.2), SlackWare (all versions), and Aurora Linux (Corona release - based on Fedora Core 6)... last but not least... i'd like to give my appreciation to everyone involved with the GlusterFS project... it is, by far, the most enjoyable (both conceptually and functionally) high performance filesystem solution i've worked with to date, and i'm hoping to move from "testing" to "working with" it... B. Karhan simon at pop.psu.edu PRI/SSRI Unix Administrator
