Hi
Perhaps if you clear everything. then remove the filesystem from dpm dpm-rmfs and add it back. dpm-addfs.
I think I tried that recently for a fs that was reporting dodgy numbers and it worked. If not - then we can dig more into if there is something in the db causing problems.
Cheers
Wahid
On 7 Jul 2010, at 11:45, Chris Curtis wrote:
> Hi -
>
> The rfrm command didn't help. So I removed the file with normal rm and then tried del-replica, which complained about not finding the file (!), but appeared to remove the replica name from the dpm-disk-to-dpns output.
>
> I've released most of the disk space this way, and according to df, I'm only using 20GB of the target filesystem. dpm-qryconf suggests that I'm still using 125GB. Where is this mismatch coming from?
>
> Cheers,
>
> Chris
>
>
> On Tue, 6 Jul 2010, Wahid Bhimji wrote:
>
>> Maybe try rfrm first as that will delete the db entry as well.
>> If you just delete the physical copies then there is a danger that someone accessing the file would get pointed to the non existent replica.
>> But if they are old and noone will access them then of course it is not a problem.
>>
>> Wahid
>>
>> On 6 Jul 2010, at 10:13, Chris Curtis wrote:
>>
>>>
>>> Hi -
>>>
>>> Not sure I understand the permissions on these files. I imagine that they're older than the DPM (Ivan hasn't been part of the ATLAS collaboration for nearly 4 years), so I guess they were added when the SE was converted from ClassicSE to DPM.
>>>
>>> The sample files that I have looked at do physically exist. Their permissions are typically "-rw-rw-r-- 1 prdops01 1307" (I think the owner being OPS is a coincidence of UIDs in this case - other fils have unknown owners).
>>>
>>> dpm-getacl returns:
>>>
>>> # owner: atlassgm
>>> # group: atlas
>>> user::rw-
>>> group::rw- #effective:rw-
>>> other::r--
>>>
>>> Is it safe to just rm these files, or is there a more DPM'ish solution?
>>>
>>> Chris
>>>
>>>
>>>
>>>
>>> On Tue, 6 Jul 2010, Sam Skipsey wrote:
>>>
>>>> Hi Chris,
>>>>
>>>> Actually, the file being in the state "being deleted" means that drain
>>>> already replicated it, but failed to delete it afterwards. So, it
>>>> should be safe to delete such files.
>>>> I tend to do this with a loop over files on that filesystem (from
>>>> dpm-list-disk or similar) and dpm-delreplica them... so it's
>>>> interesting to me that you can't. Do the files definitely exist on the
>>>> disk at the moment? What does dpns-getacl think their permissions are?
>>>> (What does the disk in question think its physical files permissions
>>>> are?)
>>>>
>>>> Sam
>>>>
>>>> On 5 July 2010 22:57, Chris Curtis <[log in to unmask]> wrote:
>>>>> Hi -
>>>>>
>>>>> I'm trying to drain a filesystem, but I get a large number of error
>>>>> messages:
>>>>>
>>>>> The file
>>>>> epgse1.ph.bham.ac.uk:/disk/f3b/atlas/logfiles/hollins/pythia/simul/rome.983000.simul.B2_300/rome.983000.simul.B2_300._00011.job.log.1
>>>>> is recorded as being in the process of being deleted, ignoring it during
>>>>> drain
>>>>>
>>>>> I happen to know that these files are very old, and will not be used again.
>>>>> Can I do anything about this message? (Because there are so many, I'm
>>>>> concerned I might be missing some other messages, plus I can't seem to move
>>>>> beyond ~75% free on this filesystem).
>>>>>
>>>>> I've tried a manual replicate of some of the files, which appears to be
>>>>> successful (no error reported). If I then try and dpm-delreplica, I get
>>>>> Error 13 (Permission denied).
>>>>>
>>>>> How can I drain this disk?
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Chris
>>>>>
>>>>
>>>
>>> --
>>> West 326
>>> Physics and Astronomy
>>> University of Birmingham
>>> Edgbaston
>>> Birmingham
>>> B15 2TT
>>>
>>> (Office) 0121 414 4700
>>> (Mobile) 0798 666 1959
>>
>>
>>
>
> --
> West 326
> Physics and Astronomy
> University of Birmingham
> Edgbaston
> Birmingham
> B15 2TT
>
> (Office) 0121 414 4700
> (Mobile) 0798 666 1959
>
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
|