
On Mon, Dec 1, 2014 at 5:12 PM, Roman Bysh <rbtc1@rogers.com> wrote:
On 12/01/2014 04:20 PM, Greg Freemyer wrote:
On Mon, Dec 1, 2014 at 3:12 PM, Roman Bysh <rbtc1@rogers.com> wrote:
I really wanted to like btrfs. IMHO Snapper is silently taking way too many snapshots. I think that a snapshot message should pop up letting the user know. Otherwise I have to go in and delete a lot of the snapshots.
I think snapper is pretty efficient and only files like database files of VM backend storage consumes drastically more space if there are lots of snapshots.
As a simple example, assume I have a collection of 3 1 GB files and I delete 1 of them each day for 3 days. Further I assume I make a nightly snapshot.
Day 1: Snapshot 1 created - currentlyempty File 1 deleted - behind the scenes it is moved to snapshot 1
Day 2 Snapshot 2 created - currently empty - Snapshot 1 is effectively frozen File 2 deleted - behind the scenes it is moved to snapshot 2
Day 3 Snapshot 3 created - currently empty - Snapshot 2 is effectively frozen File 3 deleted - behind the scenes it is moved to snapshot 3
So at the end of the day, I have 3 snapshots, each 1GB in size.
If you delete snapshot 2, then its contents are merged with snapshot 1, so now snapshot 1 is 2GB and snapshot 3 is 1GB.
Thus for static file creation / deletion scenarios, btrfs is very efficient and you don't really recover any disk space until you delete the oldest snapshot.
Where btrfs falls down with lots of snapshots is when you have a file like a database where the same data blocks routinely have different content.
Then each of the snapshots has to maintain the content of the data blocks redundantly.
ie. dnapshot 1 has the contents of the changing data blocks as of the morning of Day 1, Snapshot 2 has the day 2 content, etc.
I believe therefore that it is recommended to disable COW snapshot functionality on database files.
The same logic applies to VM virtual disks, so there too it is recommended to disable COW functionality.
Thus if you are following the guidelines to disable COW on problematic files, then there is very little penalty associated with having lots of snapshots.
Greg -- Greg Freemyer
Greg,
You are a great teacher! I was unaware of this! Is it possible for you to add your knowledge to the openSUSE wiki on btrfs?
I do edit the wiki on occasion but not for btrfs. One reason is my true expertise is with Windows NTFS shadow copies. I have to work with them at a detail level in my day job (computer forensics). NTFS shadow copies are very similar to btrfs snapshots. Also since NTFS shadow copies have been in production use for over a decade there is lots of documentation / reverse engineering in place for shadow copies.
There is so much that users do not know about the btrfs.
I also am not expert. I've barely tinkered with btrfs, but I understand COW in great detail from other storage systems / file systems.
I've encountered a csum error problem that corrupted my filesystem.
See below:
<-- snip --------------------------------------------------------- If I type "make" in /usr/src/linux - I get an error:
make /bin/sh: line 1: 5471 Bus error ( ar rcD "$TMP" ) > /dev/null 2>&1 HOSTCC scripts/basic/fixdep gcc: internal compiler error: Bus error (program as) Please submit a full bug report, with preprocessed source if appropriate. See <http://bugs.opensuse.org/> for instructions. scripts/Makefile.host:118: recipe for target 'scripts/basic/fixdep' failed make[2]: *** [scripts/basic/fixdep] Error 4 Makefile:475: recipe for target 'scripts_basic' failed make[1]: *** [scripts_basic] Error 2 HOSTCC scripts/basic/fixdep gcc: internal compiler error: Bus error (program as) Please submit a full bug report, with preprocessed source if appropriate. See <http://bugs.opensuse.org/> for instructions. scripts/Makefile.host:118: recipe for target 'scripts/basic/fixdep' failed make[1]: *** [scripts/basic/fixdep] Error 4 Makefile:475: recipe for target 'scripts_basic' failed make: *** [scripts_basic] Error 2 <-- snip ----------------------------------------------------------
I have only been running it for one month. I'm unable to work with the Linux kernel source. Please see mhy earlier posts.
Is this a rare occurrence? The tools were not able to fix the csum errors.
Should I reinstall with btrfs. How would you create your first pre and post snapshot after the initial installation using snapper?
Sorry, I'm just mister theory for btrfs, you have transitioned to practice!
Any thoughts?
Roman
Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org