Menu
▾
▴
Re: [Moosefs-users] Reserved files remain forever
|
From: Michal B. <mic...@ge...> - 2011-03-21 09:22:51
|
Hi! Lazy umount should work with MooseFS (if the oparating system supports is). You just need to try it, eg.: "umount -l /mnt/mfs ; mfsmount /mnt/mfs" Regards Michal -----Original Message----- From: Flow Jiang [mailto:fl...@gm...] Sent: Thursday, March 17, 2011 3:57 PM To: Michal Borychowski Cc: moo...@li... Subject: Re: [Moosefs-users] Reserved files remain forever Great! Looking forward to try MFS 1.6.21. Would it also work with lazy umount (umount -l)? Seems that AutoFS will use lazy umount under some circumstances like a forced shutdown / reboot, but I'm not so sure about this. Thanks Flow On 03/16/2011 10:02 PM, Michal Borychowski wrote: > Hi! > > We added a small change in 1.6.21, ie. while umounting, mfsmount will now > send a "close session" command to the master. Such properly closed sessions > would not be "hanging" throughout this 7-day period. > > > Kind regards > Michal > > > -----Original Message----- > From: Flow Jiang [mailto:fl...@gm...] > Sent: Tuesday, March 01, 2011 5:06 PM > To: moo...@li... > Subject: Re: [Moosefs-users] Reserved files remain forever > > O.K. I think I lied in the last post. I changed all our configuration to > use fstab mount the FS permanently and use "-fstype=bind" for AutoFS to > link it to user home. But I still have more than 100 reserved files > today, most of them look like temp files. (like > .local|share|gvfs-metadata|home-8a63e833.log) > > The interesting thing is that we have nightly builds running on > non-UserHome MooseFS mounted directory, which also creates / deletes > temp files, but non of them gets reserved. So I suspect this might be > caused by the way applications write file. > > So my question is that does any one has the similar issue when MooseFS > is serving as home? Do you have reserved files remaining for a long > time? And they will be deleted after 1 week, right? > > BTW, the "-fstype=bind" work around do fixes the Core Dump issue. > > Thanks > Flow > > On 02/27/2011 01:20 AM, Flow Jiang wrote: >> Hi, >> >> I now know how to re-create the issue and it should also be related to >> AutoFS. >> >> I noticed that if I make a new file with non-zero size and delete it >> immediately, it will be set as reserved file and keep at this state >> for a while (about 1 minute in our environment). If the underlying >> MooseFS is unmounted within this short period, the behavior differs >> between fstab mounted FS and AufoFS mounted FS. >> >> * If the FS is mounted by fstab, create and delete a file, then >> unmount the FS, the file eventually gets deleted >> * If the FS is mounted by autofs, create and delete a file, then >> unmount the FS, the file remains as reserved forever >> >> And unfortunately we are relying on the timeout feature of AutoFS so >> unmount happens frequently. This is the reason we have so many cache >> files (created then deleted during one mount session) remaining as >> reserved files forever. >> >> Our AutoFS mount option is mentioned in the other thread >> > (http://sourceforge.net/mailarchive/forum.php?thread_name=4D68E18F.3000708%4 > 0gmail.com&forum_name=moosefs-users). >> And the issue looks like the same: >> >> * If the FS is mounted by fstab, writing a file (> 1M) to some folder >> then unmount it, works O.K. >> * If the FS is mounted by autofs, writing a file (> 1M) to some folder >> then unmount it, core file gets dumped >> >> Increasing autofs timeout would help for the reserved file issue but >> not for the core dump issue. And even if the timeout is increased, a >> restart / power off of the system still won't leave enough time for >> the file to be totally deleted. >> >> I do have a work around to fix the 2 issues temporarily, by mounting >> the entire MFS system with fstab and use "-fstype=bind" option in >> autofs to make auto mounting/unmounting happen. But this is >> complicated and different mfs mount options can't be set with >> different subfolders. So I do hope I can have native AutoFS supported >> MooseFS mounts. >> >> Can any one help on this? >> >> Many Thanks >> Flow >> >> On 02/22/2011 12:03 AM, Flow Jiang wrote: >>> Hi, >>> >>> Just found another issue. I cleared about 10000 reserved files with >>> the script provided at >>> > http://sourceforge.net/tracker/?func=detail&aid=3104619&group_id=228631&atid > =1075722 >>> yesterday, and this morning I had 0 reserved file when started working. >>> >>> However, after one day development activity with 6 workstations, now >>> we have 204 reserved files not deleted. I've noticed it's stated that >>> "Each session after two hours is automatically closed and all the >>> files are released." in above link, but seems it's not happening in >>> our environment. We have CentOS 5.5 x86 servers and run mfsmount on >>> Fedora 12 x64 workstations. Both servers and workstations run mfs >>> 1.6.19. And mfs is serving as home with read / write access. >>> >>> Here are some example of the reserved files by reading the metadata: >>> >>> > 00067856|UserHome|tompan|.mozilla|firefox|mk9e32d7.default|OfflineCache|inde > x.sqlite-journal >>> > 00067857|UserHome|tompan|.mozilla|firefox|mk9e32d7.default|OfflineCache|inde > x.sqlite-journal >>> >>> Most of the 204 reserved files look like temp / journal files. >>> >>> Any ideas about the cause of the issue? >>> >>> BTW, OpenOffice fails to start if MFS serves as home directory. It >>> should be a FS bug as stated on: >>> http://qa.openoffice.org/issues/show_bug.cgi?id=113207. Would it be >>> related to the issue above? And can we fix this OOo issue? >>> >>> Many Thanks >>> Flow >>> >>> >>> >>> >>> >>> >>> > ---------------------------------------------------------------------------- > -- > Free Software Download: Index, Search& Analyze Logs and other IT data in > Real-Time with Splunk. Collect, index and harness all the fast moving IT > data > generated by your applications, servers and devices whether physical, > virtual > or in the cloud. Deliver compliance at lower cost and gain new business > insights. http://p.sf.net/sfu/splunk-dev2dev > _______________________________________________ > moosefs-users mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moosefs-users > ---------------------------------------------------------------------------- -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ moosefs-users mailing list moo...@li... https://lists.sourceforge.net/lists/listinfo/moosefs-users |
