Hi!
This is not trash, but "reserved" files. The file is kept opened by one of
the mfsmounts. You need to find the process and kill it.
You need to run grep over "metadata.mfs.back" looking for i-node and "R",
something like:
"mfsmetadump metadata.mfs.back | grep ^R | grep 298219"
The outcome would be similar to:
R|i: 298219|#:2|e:0|m:0644|u: 536|g:
100|a:1310025540,m:1310025550,c:1310025551|t: 0|l:
12345678|c:(00000000XXXXXXXX,.....)|r:(NNNNNNN)
NNNNNN is the number of the session (visible in CGI monitor - session_id in
Mounts tab) which keeps the file in the system.
Kind regards
Michał Borychowski
MooseFS Support Manager
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Gemius S.A.
ul. Wołoska 7, 02-672 Warszawa
Budynek MARS, klatka D
Tel.: +4822 874-41-00
Fax : +4822 874-41-01
From: Rajeev K Meharwal [mailto:raj...@gm...]
Sent: Wednesday, July 06, 2011 3:53 PM
To: moo...@li...
Subject: [Moosefs-users] under goal chunks and reserved file in meta data.
Hi All,
Can some one help me with the following situation. CGI interface is
showing 1 under goal chunk (red), and gui is reporting this file under
'reserved' metadata area. This is showing for more than 2 weeks now.
currently unavailable chunk 00000000003791F5 (inode: 298219 ; index: 2)
+ currently unavailable reserved file 298219:
[File_Path_snipped...]/mytestfile
unavailable chunks: 1
unavailable reserved files: 1
I have trash quarantine setup for 2 days. Per documentation, files in
'reserved' metadata area are deleted files, but still open by some process
and MFS will remove these once the file is closed. I have restarted master,
all chunk servers and rebooted client from where this file was actually
written in the first place. I mounted (META) data area and can see
corresponding file under 'reserved' directory, but can not remove from
there.
Any other way to clean this up?
rxknhe
|
