Installed this weekend, so pretty close to a fresh install. I’m getting the following error, primarily on the very large image jupyter/datascience-notebook. It seems to happen at different points (the below is the furthest it’s been).
Turn snapshotting off, or re-install selecting ext4 instead of btrfs.
There is really no point in snapshotting storage for virtualization or containers, if you even had to rollback for <any> reason <every> image would be rolled back undoing changes in every one.
And, that’s on top of the massive numbers and sizes of snapshots you’d be creating if changes are being made to more than one container at once.
Same issue here, docker on btrfs was working fine, but broke probably kernel/docker update (last week-ish?). It fails even downloading 47.58 MB of data:
leap: Pulling from library/opensuse
d7ceceec7bf6: Extracting 47.58 MB/47.58 MB
failed to register layer: ApplyLayer exit status 1 stdout: stderr: open /var/lib/ca-certificates/openssl/T__RKTRUST_Elektronik_Sertifika_Hizmet_Sa__lay__c__s___H5.pem: no space left on device
There’s an intermittent issue with BTRFS where it reports out of space even when there’s plenty of it left - temporary triage; disable quota on the drive.
IMO: btrfs is a piece of ****. Whoever had the great idea of making it the de facto in openSUSE needs to get kicked in the balls, hard.
You need to supply plenty of space for snapper. Normal Linux tools do not report correct space when snapper is involved. IMHO BTRFS with snapper has a place but most users in most desktop situation don’t really need it. It is great for developer or Tumbleweed uses that may need to roll back often but Leap users for the most part can get by with EXT4 just fine. There is no real difference in performance between BTRFS and EXT4
I doubt this problem has to do anything with snapper, I removed all the snapshots and the problem still persists. I agree that using tools like df may yeld inaccurate results but btrfs fi df should always be fine. IMO there is a bug in docker/btrfs kernel driver introduced in one of the recent updates. Will fire a bugzilla ticket later today.
I’ve come across some info that calls into question my posted recommendation…
BTRFS has the ability to restore individual files with the following command, so you don’t have to roll back an entire partition
btrfs restore
That said,
BTRFS provides this highly desirable feature at a price… Compared to other fs BTRFS can be prohibitively slow, particularly if you’re supporting intensive disk I/O. So, BTRFS is highly discouraged when deploying a relational database or similar. You could probably extrapolate that recommendation to some highly intensive frontend apps. But, many if not most apps don’t behave this way so BTRFS might be “OK” for most apps.
If you want the features BTRFS provides, it is probably a better choice than others, BTRFS is particularly well known for performaing relatively better than all other current OS when writing metadata, the stuff things like snapshots and file recovery relies upon.
Although not ordinarily relevant to Docker, when considering BTRFS for storing virtualization images (eg VMware, VBox, KVM, Xen, etc), there are some articles which highly recommend making the virtual disk fs RAW or similar, and specifically to avoid COW and QCOW which is the default for KVM systems to avoid possible write amplification.
Lastly, of course this means that if you implement BTRFS on a multi-OS system like Docker or any of the Virtualization technologies, it’s imperative to create your own BTRFS config to discard old snapshots at a faster rate than default.