August 25, 201411 yr I had this error today on 6b7. If I store a location for appdata on a btrfs drive in the array: "/mnt/disk9/appdata" works but "/mnt/user/appdata" gives an out of space in a docker container log Could be related?
August 25, 201411 yr Hmm, ok this is probably serious enough for us to get out a -beta7a asap. Issue is that by default, btrfs uses "Copy on Write": https://wiki.archlinux.org/index.php/Btrfs#Copy-On-Write_.28CoW.29 This is a behavior to be aware of and we need to add some controls: a) disable cow for an entire device b) disable cow for an entire share The docker share must be on a btrfs volume with cow enabled. But shares that will experience a lot of small file updates probably should not be cow.
August 25, 201411 yr ... b) disable cow for an entire share The docker share must be on a btrfs volume with cow enabled. But shares that will experience a lot of small file updates probably should not be cow. Even when using a cache-only user share for apps many people typically refer to it as /mnt/user/appdata instead of /mnt/cache/appdata, for example. I know I always have, and I think the docker templates that are in common use are configured this way as well. If have even seen recommendations to do it this way. Many people have been using a btrfs cache drive with container data also stored on that same btrfs cache drive. If docker must be on a btrfs volume with cow enabled, does this mean that volume cannot contain a share without cow?
August 25, 201411 yr I think I will stay on 6b6 while this plays out. I have just ordered another SSD. I was going to add it to the cache pool, but may have to use it as a separate app drive instead.
August 25, 201411 yr I think I will stay on 6b6 while this plays out. I have just ordered another SSD. I was going to add it to the cache pool, but may have to use it as a separate app drive instead. Do not see much point in staying on b6 which has known issues. I would suggest moving to b7, but just avoid using this new feature.
August 25, 201411 yr I think I will stay on 6b6 while this plays out. I have just ordered another SSD. I was going to add it to the cache pool, but may have to use it as a separate app drive instead. Do not see much point in staying on b6 which has known issues. I would suggest moving to b7, but just avoid using this new feature. I might go to b7 if b7a does not happen soon, but this is not really a new feature. This is the way we have been using it since docker was implemented on b6. It is b7a that limetech is talking about which would be a new feature (or fix) to avoid these problems. Since I have limited bays and ports on my server I need to see how to best use another SSD going forward.
August 25, 201411 yr Well, it will be a few days before my new SSD arrives and maybe we will have more direction on this by then. It sounds like docker really should be on its own drive and not on a cache drive, at least not as traditionally used for caching writes and storing frequently accessed app data. Or maybe it could be on a cow share on a btrfs drive that has other shares without cow. I don't really know anything about the details.
August 26, 201411 yr We have a proposed solution to this, see here: http://lime-technology.com/forum/index.php?topic=34830.0
Archived
This topic is now archived and is closed to further replies.