Apache OpenOffice (AOO) Bugzilla – Issue 4898
OpenOffice cannot be launched from MFS partition
Last modified: 2017-05-20 11:29:23 UTC
OpenOffice 1.0.0 cannot be launched from MFS (MOSIX) filesystem. Here's the reason why: access("/home/shel", F_OK) = 0 statfs("/home/shel", {f_type=0xe08f018, f_bsize=1024, f_blocks=1048576, f_bfree=409600, f_files=547411, f_ffree=50000, f_namelen=255}) = 0 open("/home/shel/.user60.rdb", O_RDWR) = 10 shmat(10, 0x1, 0x1ptrace: umoven: Input/out(10, 0x2, 0x2ptrace: umoven: Input/output error) = ? lseek(10, 0, SEEK_END) = 512 old_mmap(NULL, 512, PROT_READ|PROT_WRITE, MAP_SHARED, 10, 0) = -1 EPERM (Operation not permitted) --- SIGSEGV (Segmentation fault) --- +++ killed by SIGSEGV +++ Here the link is: /home/shel->/mfs/1/local/shel. That's the answer I've got from MOSIX developers about this problem: "The "mmap" system-call with MAP_SHARED is in fact requesting that the mapped file be used as shared-memory. You can find in the MFS documentation that this feature is not supported: it would be very difficult to support such generic cluster-wide shared-memory (DSM), and even if implemented, the performance would be disastrous, and of course, being a form of shared-memory, MOSIX would have to force all such processes that use this feature to stay on their home-node. I don't know what to suggest at this time other then investigate why Office requires this feature: in most cases, this is not really intended as true shared-memory, but rather as a form of lazy-write: if so, it should be converted to map with MAP_PRIVATE (at least if mapping with MAP_SHARED failes), then use the "write" system-call instead of msync/close." Any ideas how to fix this?
TM->FT: I think this one is more a request for a feature or an enhancement than a bug. Please have a look at it. Thanks !
Can you please give good reasons why we should put resources in this IMO rather scarce problem? Thx.
Well, this makes open office not usable on MFS. And that means that there's no suitable technology for SSI-like linux system based on cluster of linux workstations as major (only) office software will not work on this system. The only solution of this problem without modification of Open Office code I can see is usage of NFS for homespace and this will run slower. I'm afraid I cannot give better reason then this. Any way if you will decide that this problem is not worth you effort, why not put into documentation/release notes that Open Office is not MFS compatible?
Hi Evgeniy, Well, at least I haven't ever heard of a MFS filesystem, and probably others as well. That might be the reason why it's not mentioned at all. But back to the facts. The reason why this happens at all, is that the 'fs_type' returned by 'statfs()' is not recognized as a 'remote' file- system like NFS. In case it would have been recognized as such, the code involved would have switched back to 'read()' / 'write()' system calls instead of 'mmap()'. I have no proper solution for now, but I'll take this issue. And thanks for the detailed diagnose, that saves the debugging stage for me. Matthias
Reassigning to myself.
Module 'ucb/store' doesn't recognize MFS (MOSIX File System) as remote. Look at 'fs_type' check in 'porting/sal/osl/unx/file.c', function 'osl_getVolumeInformation', which currently recognizes NFS and SMB as remote via their respective superblock magic numbers.
Well, I've got the idea, nice that it can be corrected. Two ways, either I patch MFS statfs call to pretend to be NFS, but this is potentially dangerous. So better to patch Office code, the magic number for MFS is: statfs.f_type=235466776 Meanwhile I can try to set the same handling as for NFS in 'porting/sal/osl/unx/file.c', function 'osl_getVolumeInformation' and test it. Silly question, where do I get the sources of the stable 1.0.0 release? I don't want to deal with snapshots as there can be other buggies :@) Evgeniy
Hi Evgeniy, Thanks for the 'magic' number. Silly, or not, a link to download the source is in the left navbar on the main web page: Downloads - Application / Source / Developer. If you haven't compiled the source before, you probably need to be warned that OpenOffice.org is quite large. But you only need to build up to the 'sal' project, which happens to one of the lowest level modules. Good luck, Matthias
Hi Hennes, Reassigning to you, as discussed. Should go into OOo 1.0.1, if possible. Thanks, Matthias
Accepted.
Added magic number for Mosix file system to /sal/osl/unx/file.c Revision 1.51.2.8. Committed to branch OOO_STABLE_1.
Hi, The bug is still there in 1.0.1 though there is some code in source in file.c to handle MFS, If I install a binary, I still get the same crush. ?? Regards Evgeniy
removed keyword "ooo1.0" in favour of a target milestone "OOo 1.0.2".
Don't have further informations needed to fix the bug.
.
is this still an issue ?
mav: Please take over.
Reset assigne to the default "issues@openoffice.apache.org".