 |
 |
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.