I got it sorted out. I reinstalled snapper and using it I could delete all the / snapshots except "0". It wouldn't let me delete the /home snapshots because my messing around trying to delete them probably deleted the info.xml file.
So, I tried booting into a LiveCD and mounting my /dev/sda4 and using mc again, but the results were the same. While I was usiing the LiveCD I umounted /dev/sda4 and ran the btrfs check against it. No errors were reported. I googled for "snapper can't delete snapshot" and found a post by the guy who wrote snapper. He said that only the parts of the path named "snapshot" are subvolumes. The ".snapshots" and the numbered parts regular directories. So, I tried
sudo btrfs subvolume delete /home/.snapshots/114/snapshot
and it worked! I quickly deleted all the remaining snapshots on both / and /home. I used rmdir to remove /home/.snapshots/114 and the rest of the leftovers. Then I defraged / and /home and the meta data and then ran scrub.
I am back up to 70% free according to df and I've USED 73% (89GB out of 121GB on a 336GB partition) according to btrfs fi df / the remaining "unused" portion being reserved for the potential creation of a snapshot of the entire system.
1) The btrfs filesystem is very stable. And, it does not need swap partitions, so don't waste your disk space on swap if you want to use btrfs. Considering all the violence I did to it, it while learning how to use it, it never misbehaved and the btrfs check /dev/sda4 on the unmounted volume showed no errors. The documentation, however, is sparse. Btrfs is still is in such rapid development that writing extensive documentation at the current time would be mostly a wasted effort. Fortunately, if you use Google Search's time limitations to restrict your search to recent documents, and to Ubuntu or debian based documentation, information is not hard to find.
2) Btrfs is, IMO, not meant for single HDs or a single partition unless that HD or partition is TWICE OR 3X as big as the maximum size of your anticipated storage needs. My 336GB partition barely qualifies, IMO. After Kubuntu and all of my favorite apps are installed, and with NO snapshots, the size of @ and @home combined uses 90GB out of 121GB. IF I read "btrfs fi /" right, I have only 31GB of unused space left on which to install more apps or save more data before my btrfs filesystem becomes full. By comparison, a 336GB EXT4 partition would show about 30GB taken with Kubuntu and about 300GB remaining for additional applications and data, which is 10X as much as btrfs makes available with the same installs. However, the ability to easily add or remove other storage devices with relative ease, and the ability to make snapshots of your system and to roll back if adversity hits, makes it a worthwhile install, IMO. Certainly a lot easier than making tar backups of critical files and/or copyng them to other devices or locations and then doing the OS reinstall and copy routine. I have an active 7 port USB device plugged into my Acer. I could plug in 7 64GB USB sticks (448GB, of which about 120GB woudl be usable) and add them to my storage pool. Or, I could plug in my 350GB USB HD and get the same usable space. With development proceeding things can only get better. One caution: if you do something like that, and come close to filling up that additional space, you will have to add even more devices to give you working room while you trim down your stored files. Also, If you boot off of an EXT4 /boot partition be advised that snapshots do not apply, so rollbacks of Muon updates will not revert to the previous kernel, but the current kernel's headers in /usr/src will be gone.
3) Snapper , as Oshunlover said, is NOT ready for primetime. And, I doubt it will ever be because of design flaws, one of which is too many snapshots automatically created. True, one can change the snapper config settings, but then it becomes a matter of which ones are critical and how do you specifically tell snapper to do only those? Snapper isn't that fine grained, which is why it appears to me that custom shell scripts will do better. Snapshots can quickly eat up your disk space. It would be a LOT easier and more compatible to use btrfs commands in a shell script to do activities similar to that which snapper does, and have those scipts tailered exactly to your needs, and run ONLY when you need them. Snapper allows one to manually create "pre" and "post" snapshots and execute a command in between, which is something that one might want to do when using apt-get or when the Muon updater runs. The pre and post numbers which snapper uses to identify its snapshots can be used to remove changes made between then before they are deleted. Thus, "snapper -croot delete nn..mm" and "snapper delete -chome nn..mm" is supposed to remove any changes to the system caused by any commands run between those two snapshots. Enter apt-btrfs-snapshots.
4) The package apt-btrfs-snapshots is supposed to automatically make pre and post snapshots when ever apt-get is run, either in a console or by use of a wrapping gui. That's when I thought about snapper and apt-btrfs-snapshot busily churing away, breeding children automatically. The number of automatic snapshots being created on my system was eating my free space alive! Limiting snapper's snapshots to 4 each for @ and @home, but not being able to limit apt-btrfs-snapshots it became clear that after a few Muon updates and some apt-get update & apt-get upgrades of my own I realized that I had less than a week's worth of disk space remaining. I quickly purged apt-btrfs-snapshots but, to my dismay, it did NOT delete the snapshots it made! Fortunately, all of them were created as unmounted subvolumes, i.e., "@apt-snapshot-yyyymmddhh:mm:ss" on the partition my system was running on. It was easy to mount /dev/sda4 to /mnt and use " btrfs subvolume delete @apt-snapshot-yyyymmddhh:mm:ss", then umount.
5) Btrfs by itself is adequate. Be sparse with your snapshots. To give you and example of the power of btrfs on Kubuntu read the following article about making backups of your home account using " btrfs sub create": http://arstechnica.com/information-t...filesystems/3/