On Fri, Mar 20, 2015 at 4:03 PM, Chris Murray <chrismurra...@gmail.com> wrote:
> Ah, I was wondering myself if compression could be causing an issue, but I'm
> reconsidering now. My latest experiment should hopefully help troubleshoot.
>
> So, I remembered that ZLIB is slower, but is more 'safe for old kernels'. I
> try that:
>
> find /var/lib/ceph/osd/ceph-1/current -xdev \( -type f -o -type d \) -exec
> btrfs filesystem defragment -v -czlib -- {} +
>
> After much, much waiting, all files have been rewritten, but the OSD still
> gets stuck at the same point.
>
> I've now unset the compress attribute on all files and started the defragment
> process again, but I'm not too hopeful since the files must be
> readable/writeable if I didn't get some failure during the defrag process.
>
> find /var/lib/ceph/osd/ceph-1/current -xdev \( -type f -o -type d \) -exec
> chattr -c -- {} +
> find /var/lib/ceph/osd/ceph-1/current -xdev \( -type f -o -type d \) -exec
> btrfs filesystem defragment -v -- {} +
>
> (latter command still running)
>
> Any other ideas at all? In the absence of the problem being spelled out to me
> with an error of some sort, I'm not sure how to troubleshoot further.
Not much, sorry.
> Is it safe to upgrade a problematic cluster, when the time comes, in case
> this ultimately is a CEPH bug which is fixed in something later than 0.80.9?
In general it should be fine since we're careful about backwards
compatibility, but without knowing the actual issue I can't promise
anything.
-Greg
_______________________________________________
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
