Oh, and thanks for the "filestore btrfs snap = false" pointer.  In
ceph.conf, under [osd], I assume?


On Mon, Jun 2, 2014 at 10:07 AM, Scott Laird <[email protected]> wrote:

> FWIW, I figured out the ceph "out of memory" error that was keeping me
> from recovering one FS:
>
> # ls -l /mnt
> ls: cannot access /mnt/snap_3415219: Cannot allocate memory
> total 5242920
> -rw-r--r-- 1 root root        472 May 23 19:16 activate.monmap
> -rw-r--r-- 1 root root          3 May 23 19:16 active
> -rw-r--r-- 1 root root         37 May 23 19:14 ceph_fsid
> drwxr-xr-x 1 root root      11688 May 31 15:10 current
> -rw-r--r-- 1 root root         37 May 23 19:14 fsid
> -rw-r--r-- 1 root root 5368709120 Jun  2 08:11 journal
> -rw------- 1 root root         56 May 23 19:16 keyring
> -rw-r--r-- 1 root root         21 May 23 19:14 magic
> -rw-r--r-- 1 root root          6 May 23 19:16 ready
> d????????? ? ?    ?             ?            ? snap_3415219
> drwxr-xr-x 1 root root      11688 May 31 15:10 snap_3415260
> drwxr-xr-x 1 root root      11688 May 31 15:10 snap_3415296
> -rw-r--r-- 1 root root          4 May 23 19:16 store_version
> -rw-r--r-- 1 root root         69 May 29 22:34 superblock
> -rw-r--r-- 1 root root          0 May 23 19:16 upstart
> -rw-r--r-- 1 root root          2 May 23 19:16 whoami
>
> snap_3415219 is clearly corrupt.  I'm going to duplicate the filesystem
> (it's only 50G, doesn't take long) without the file and see if that'll work.
>
>
> On Mon, Jun 2, 2014 at 9:51 AM, Dmitry Smirnov <[email protected]>
> wrote:
>
>> On Mon, 2 Jun 2014 17:47:57 Thorwald Lundqvist wrote:
>> > I'd say don't use btrfs at all, it has proven unstable for us in
>> production
>> > even without cache. It's just not ready for production use.
>>
>> Perception of stability depends on experience. For instance some consider
>> XFS
>> to be ready for production but it does not tolerate power loss which lead
>> to
>> loss of data. Also fixing corrupted XFS may not be possible due to
>> xfs_repair
>> memory requirements.
>>
>> Ready for production or not depends on testing (building confidence) and
>> understanding limitations. As a matter of fact Btrfs is very stable and
>> reliable on recent kernels (3.11+) if used pretty much as ext4 i.e.
>> without
>> advanced features (e.g. snapshots, subvolumes etc.).
>>
>> Linux 3.14.1 is affected by serious Btrfs regression(s) that were fixed in
>> later releases.
>>
>> Unfortunately even latest Linux can crash and corrupt Btrfs file system if
>> OSDs are using snapshots (which is the default). Due to kernel bugs
>> related to
>> Btrfs snapshots I also lost some OSDs until I found that snapshotting can
>> be
>> disabled with "filestore btrfs snap = false".
>>
>> So far I'm very happy with Btrfs stability on OSDs when snapshots are
>> disabled.
>>
>> --
>> Cheers,
>>  Dmitry Smirnov
>>  GPG key : 4096R/53968D1B
>>
>> ---
>>
>> Every decent man is ashamed of the government he lives under.
>>         -- H. L. Mencken
>>
>> _______________________________________________
>> ceph-users mailing list
>> [email protected]
>> http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
>>
>>
>
_______________________________________________
ceph-users mailing list
[email protected]
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com

Reply via email to