[opensuse-kernel] BtrFS Usage/Complaints
Hi all - Over the past year, btrfs has received substantial attention in the areas of both stability and performance. I've been running it, personally, on a 4 TB data volume as well as my root partitions for my openSUSE 12.2/12.3 systems. I've been able to do stress tests like a long fsmark run simultaneously with creating and removing snapshots (with syncs to force them to disk) and haven't run into any issues. David Sterba, who's been leading the charge at SUSE for btrfs stability has likewise regularly run it through an array of torture tests and has found that problems are occurring a whole lot less frequently than they have in the past. The upstream btrfs community in which we participate has also started focusing less on feature development and more on stability and performance. But these are only anecdotal data points from two file system guys and if my experiences working for a major operating systems vendor have taught me anything, it's that our users can be a lot more creative at finding ways to break things than we are. ;) So, I'd like to hear your stories. What's worked for you? What hasn't worked? What would you consider the pain points with using btrfs? Lastly, I'd like to ask that you take the opportunity to test with the latest openSUSE Factory kernel running 3.10-final. 12.3 used the 3.7 kernel since it was the most recent release going into the beta cycle and we've seen a bunch of btrfs fixes since that release. I look forward to your feedback and the opportunity to improve btrfs for the 13.1 release and future releases. Thanks! -Jeff -- Jeff Mahoney
El 03/07/13 12:23, Jeff Mahoney escribió:
So, I'd like to hear your stories. What's worked for you? What hasn't worked? What would you consider the pain points with using btrfs?
I had some problems in the past, but since 3.9 or so I have not seen them again, if I recall correctly, hell broke lose when my small SSD disk was full, there was no way to mount it, or do anything with it, issuing btrfs-zero-log to the device save the day. I suggest running tests on ENOSPC conditions ;-) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 7/3/13 12:57 PM, Cristian Rodríguez wrote:
El 03/07/13 12:23, Jeff Mahoney escribió:
So, I'd like to hear your stories. What's worked for you? What hasn't worked? What would you consider the pain points with using btrfs?
I had some problems in the past, but since 3.9 or so I have not seen them again, if I recall correctly, hell broke lose when my small SSD disk was full, there was no way to mount it, or do anything with it, issuing btrfs-zero-log to the device save the day.
I suggest running tests on ENOSPC conditions ;-)
Yep, that's tops on the list but even those have become less frequent. -Jeff -- Jeff Mahoney SUSE Labs
At Wed, 03 Jul 2013 13:05:28 -0400, Jeff Mahoney wrote:
On 7/3/13 12:57 PM, Cristian Rodríguez wrote:
El 03/07/13 12:23, Jeff Mahoney escribió:
So, I'd like to hear your stories. What's worked for you? What hasn't worked? What would you consider the pain points with using btrfs?
I had some problems in the past, but since 3.9 or so I have not seen them again, if I recall correctly, hell broke lose when my small SSD disk was full, there was no way to mount it, or do anything with it, issuing btrfs-zero-log to the device save the day.
I suggest running tests on ENOSPC conditions ;-)
Yep, that's tops on the list but even those have become less frequent.
I hit this problem when I moved the whole FS on my workstation to btrfs, and unfortunately in my case, I had to reinstall the whole system from the scratch, and lose many data. This was the worst case I met ever since Reiserfs over 10 years ago, so I gave up btrfs since then. A sudden -ENOSPC is unavoidable as a nature of COW, especially when snapshots are taken automatically. But, the behavior like this (refusing any actions including mount) is a literally disaster, which must not happen. If mount may be refused, at least a proper fsck must be provided instead of a random tool. Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Fri, Jul 05, 2013 at 07:47:47AM +0200, Takashi Iwai wrote:
I hit this problem when I moved the whole FS on my workstation to btrfs, and unfortunately in my case, I had to reinstall the whole system from the scratch, and lose many data. This was the worst case I met ever since Reiserfs over 10 years ago, so I gave up btrfs since then.
IIRC, this was the heavily patched 3.1.x based kernel from opensuse 12.1, right? Lots of backports were taken from sles kernel, but as there were newer opensuse releases available, 12.1 did not get many updates and some bugs were left. Using a recent kernel is recommended.
A sudden -ENOSPC is unavoidable as a nature of COW, especially when snapshots are taken automatically. But, the behavior like this (refusing any actions including mount) is a literally disaster, which must not happen. If mount may be refused, at least a proper fsck must be provided instead of a random tool.
Yeah the enospc situation is far from perfect, but has improved over time. david -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
At Mon, 8 Jul 2013 13:59:03 +0200, David Sterba wrote:
On Fri, Jul 05, 2013 at 07:47:47AM +0200, Takashi Iwai wrote:
I hit this problem when I moved the whole FS on my workstation to btrfs, and unfortunately in my case, I had to reinstall the whole system from the scratch, and lose many data. This was the worst case I met ever since Reiserfs over 10 years ago, so I gave up btrfs since then.
IIRC, this was the heavily patched 3.1.x based kernel from opensuse 12.1, right? Lots of backports were taken from sles kernel, but as there were newer opensuse releases available, 12.1 did not get many updates and some bugs were left. Using a recent kernel is recommended.
This was with a custom built kernel, 3.9-rc-something, IIRC. So this must have been an upstream bug.
A sudden -ENOSPC is unavoidable as a nature of COW, especially when snapshots are taken automatically. But, the behavior like this (refusing any actions including mount) is a literally disaster, which must not happen. If mount may be refused, at least a proper fsck must be provided instead of a random tool.
Yeah the enospc situation is far from perfect, but has improved over time.
I hope it sincerely :) Though, as someone already mentioned in another same thread on FACTORY ML, a sane automatic recovery would be really required, no matter how stable the filesystem is. A breakage may happen not only by a software bug but also by faulty hardware. The lack of fsck is one of the biggest hindrances for recommending btrfs for daily use, even if it's just a matter of mental ease. thanks, Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Mon, Jul 08, 2013 at 02:29:05PM +0200, Takashi Iwai wrote:
IIRC, this was the heavily patched 3.1.x based kernel from opensuse 12.1, right? Lots of backports were taken from sles kernel, but as there were newer opensuse releases available, 12.1 did not get many updates and some bugs were left. Using a recent kernel is recommended.
This was with a custom built kernel, 3.9-rc-something, IIRC. So this must have been an upstream bug.
Depends which rc it was, I've checked the -rc patch series incrementally and there were several fixes in each, some of them could cause the problems.
A sudden -ENOSPC is unavoidable as a nature of COW, especially when snapshots are taken automatically. But, the behavior like this (refusing any actions including mount) is a literally disaster, which must not happen. If mount may be refused, at least a proper fsck must be provided instead of a random tool.
Yeah the enospc situation is far from perfect, but has improved over time.
I hope it sincerely :)
Though, as someone already mentioned in another same thread on FACTORY ML, a sane automatic recovery would be really required, no matter how stable the filesystem is. A breakage may happen not only by a software bug but also by faulty hardware. The lack of fsck is one of the biggest hindrances for recommending btrfs for daily use, even if it's just a matter of mental ease.
There are some measures against bugs caused by faulty hardware, notably the checksums (disk bitrot or memory errors), block number is recorded and verified upon read (ghost writes), tree blocks reads verify the transaction id (overwritten blocks or stale). Automatic recovery should take place when it's either clear what type of error happend and that the recovery steps will not break it even more. Currently the autorecovery options offer to go back in time and try to access start from previously known to be good version (-o recovery). If the filesystem is damaged despite all the integrity checks passing, then it's in an unknown inconsistent state and I don't see many sane options to do safe automatic repair. fsck (the part that checks) verifies links between structures with regard to reference counts and owners (ie subvolumes), or the allocation structures' integrity. The basic verification has been present for a long time, what's being added over time are bugfixes that are based on user reports, or major features that are eg able to rebuild the tree structures from the ground up after a severe corruptions. That btrfs has no fsck is part of the folklore, and unlikely to disappear. I personally never had to use it on a filesystem where I keep non-testing data. david -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2013-07-12 at 17:25 +0200, David Sterba wrote:
Automatic recovery should take place when it's either clear what type of error happend and that the recovery steps will not break it even more. Currently the autorecovery options offer to go back in time and try to access start from previously known to be good version (-o recovery).
If the filesystem is damaged despite all the integrity checks passing, then it's in an unknown inconsistent state and I don't see many sane options to do safe automatic repair.
This is precisely my issue: the lack of tools to repair a broken filesystem. - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlHh2uUACgkQtTMYHG2NR9WnqQCeOuQjzXjb4rT8xqgnSY6D8FwG I2IAnRsp4ItynrXm5hUsBrXxewYV69qo =TDaz -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2013-07-03 at 12:23 -0400, Jeff Mahoney wrote:
But these are only anecdotal data points from two file system guys and if my experiences working for a major operating systems vendor have taught me anything, it's that our users can be a lot more creative at finding ways to break things than we are. ;)
So, I'd like to hear your stories. What's worked for you? What hasn't worked? What would you consider the pain points with using btrfs?
One of the things that is a roadblock for many is the lack of repair tools. Meaning a complete fsck.btrfs module.
I look forward to your feedback and the opportunity to improve btrfs for the 13.1 release and future releases.
May I suggest, if you want feedback from as many users as possible, that you ask in the main opensuse.org mail list, and in forums.opensuse.org? Specially the later, there are thousands of users there. If you don't like the web access (I don't), there is also a traditional NNTP access. The 'opensuse.org.help.prerelease-beta' group would be a good candidate. - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlHUYfkACgkQtTMYHG2NR9UUpACdEhEsI5RGmL9NgPs/Fg0cLvQh mpwAn3CLbIGAptU0GXniZCj3CbUBDgl9 =tJ+h -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Wed, Jul 03, 2013 at 07:39:54PM +0200, Carlos E. R. wrote:
But these are only anecdotal data points from two file system guys and if my experiences working for a major operating systems vendor have taught me anything, it's that our users can be a lot more creative at finding ways to break things than we are. ;)
So, I'd like to hear your stories. What's worked for you? What hasn't worked? What would you consider the pain points with using btrfs?
One of the things that is a roadblock for many is the lack of repair tools. Meaning a complete fsck.btrfs module.
If it's not complete, what's missing? I know about a few things that could be added to extend fsck/repair coverage but I'm curious about your expectations. thanks, david -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2013-07-12 at 17:29 +0200, David Sterba wrote:
On Wed, Jul 03, 2013 at 07:39:54PM +0200, Carlos E. R. wrote:
One of the things that is a roadblock for many is the lack of repair tools. Meaning a complete fsck.btrfs module.
If it's not complete, what's missing? I know about a few things that could be added to extend fsck/repair coverage but I'm curious about your expectations.
I looked at it some time ago, and it was simply a script to fool the boot process, it did absolutelly nothing. Now it is a binary, but I do not know what it does - look: cer@Telcontar:~> man fsck.btrfs No manual entry for fsck.btrfs cer@Telcontar:~> btrfsck(8) says: btrfsck is part of btrfs-progs. Btrfs is currently under heavy development, and not suitable for any uses other than benchmarking and review. Please refer to the btrfs wiki http://btrfs.wiki.kernel.org for further details. So, if the manual says it is not ready... do you really expect us to use it? ;-) eleanor3:~ # btrfsck --help btrfsck: unrecognized option '--help' usage: btrfsck dev Btrfs v0.19+ eleanor3:~ # No help? It does run, though: eleanor3:~ # btrfsck /dev/sda9 checking extents checking fs roots checking root refs found 300769280 bytes used err is 0 total csum bytes: 291300 total tree bytes: 2281472 total fs tree bytes: 1662976 btree space waste bytes: 448961 file data blocks allocated: 298487808 referenced 298487808 Btrfs v0.19+ eleanor3:~ # I do remember several posts of people using btrfs, got a broken filesystem, could do nothing to repair it but reformat and recover from backup, if it existed. Almost all of them said they were reformatting as ext3/4 instead. - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlHh2HUACgkQtTMYHG2NR9Ve5wCcCAaudMo/IRO8ONKrW92VO8Xd Sl8An3VXWU4p6SYd4ZkstFidYtEmwUIk =jzHN -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Jeff Mahoney wrote:
Lastly, I'd like to ask that you take the opportunity to test with the latest openSUSE Factory kernel running 3.10-final. 12.3 used the 3.7 kernel since it was the most recent release going into the beta cycle and we've seen a bunch of btrfs fixes since that release.
I look forward to your feedback and the opportunity to improve btrfs for the 13.1 release and future releases.
How about starting ~10 procs creating numerically incrementing files with sizes @ 128 768, 1K, 16k, 256k 32M 512M. Start them all, let them run for a few minutes, then kill power. Maybe put a fixed pattern in each so you can also verify the contents...?? Of some of those files, have them seek to end and write 1 byte. Are the remaining blocks zeroed when you read them? Are the files stored sparse? What is the optimal I/O size? (testing w/dd for example using iflags=direct oflags=direct Whats the maximum throughput? ...compared to theoretical? Seems like those would test a few things... Can they have ACL's (presuming yes), add accels to some and see if a power hit results in any problems there? Just a few "gentle" things to try out a FS. ??? -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Wed, Jul 03, 2013 at 11:47:34AM -0700, Linda Walsh wrote:
Jeff Mahoney wrote:
Lastly, I'd like to ask that you take the opportunity to test with the latest openSUSE Factory kernel running 3.10-final. 12.3 used the 3.7 kernel since it was the most recent release going into the beta cycle and we've seen a bunch of btrfs fixes since that release.
I look forward to your feedback and the opportunity to improve btrfs for the 13.1 release and future releases. ... Just a few "gentle" things to try out a FS.
Thanks for the testing suggestions. First part is about power failure safety. Besides our own tests with killing the device via /sys/block/sdx/queue/delete or turning the device RO (via blockdev), I know that Chris does similar tests and for that purpose wrote an "evil" block io scheduler that tries to simulate the really bad conditions. See here, http://lwn.net/Articles/468660/ . Physical unplugging may not be that lucky to strike between some critical blocks due to merging. Most recent bug in that area has been fixed in 3.2. The second part is about performance. I'd rather skip it for now as it's a broad topic. General performance is good, there are known workloads that behave particularly bad due to COW (VM, DB), and when fragmentation kicks it's bad (eg after lots of snapshot churn). david -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Hi Jeff, Le Wednesday 03 July 2013 à 12:23 -0400, Jeff Mahoney a écrit :
So, I'd like to hear your stories. What's worked for you? What hasn't worked? What would you consider the pain points with using btrfs?
I did not give it a try at all, sorry. Seeing the amount of bug fixes flowing continuously gave me the feeling that this filesystem was simply not ready. There is no data of mine that I am ready to jeopardize. Ext3 did the job for me back then, ext4 does the trick now (discard support convince me to change), I found absolutely no good reason to spend time and take any risk with another filesystem. So, first and foremost, I'd need a statement that btrfs is now reliable enough (apparently you're hunting for exactly that) and also a comparison with ext4 proving that btrfs is better. And not just because it is new and cool and conceptually great - I want real-world facts. -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 7/4/13 10:10 AM, Jean Delvare wrote:
Hi Jeff,
Le Wednesday 03 July 2013 à 12:23 -0400, Jeff Mahoney a écrit :
So, I'd like to hear your stories. What's worked for you? What hasn't worked? What would you consider the pain points with using btrfs?
I did not give it a try at all, sorry. Seeing the amount of bug fixes flowing continuously gave me the feeling that this filesystem was simply not ready. There is no data of mine that I am ready to jeopardize. Ext3 did the job for me back then, ext4 does the trick now (discard support convince me to change), I found absolutely no good reason to spend time and take any risk with another filesystem.
So, first and foremost, I'd need a statement that btrfs is now reliable enough (apparently you're hunting for exactly that) and also a comparison with ext4 proving that btrfs is better. And not just because it is new and cool and conceptually great - I want real-world facts.
And this is exactly the biggest problem with btrfs right now: perception. I understand where you're coming from, but this isn't the kind of response that's helpful. If the perception is to change, we need actual testing and corresponding bug reports if there are any. -Jeff -- Jeff Mahoney SUSE Labs
Jeff Mahoney wrote:
On 7/4/13 10:10 AM, Jean Delvare wrote:
Hi Jeff,
Le Wednesday 03 July 2013 à 12:23 -0400, Jeff Mahoney a écrit :
So, I'd like to hear your stories. What's worked for you? What hasn't worked? What would you consider the pain points with using btrfs?
So, first and foremost, I'd need a statement that btrfs is now reliable enough (apparently you're hunting for exactly that) and also a comparison with ext4 proving that btrfs is better. And not just because it is new and cool and conceptually great - I want real-world facts.
And this is exactly the biggest problem with btrfs right now: perception. I understand where you're coming from, but this isn't the kind of response that's helpful. If the perception is to change, we need actual testing and corresponding bug reports if there are any.
I would tend to disagree, "50%". While having proof of "it's not bad because we have 24 thousand burgers served and only 3 bugs filed, Jean has a valid point -- why would I WANT to switch from something that has 124 million burger-serving hours and no complaints? Is it faster? Is it more reliable? What's the fastest single-threaded input/output? Multi-threaded load? (compared to other FS's on same HW at same location on disk). How about small random read/writes? deletes How is performance when fragmented? Anything? Where's the positive or things like "I did an accidental "mount /dev/root /mnt && rm -fr /mnt", but I was able to recover with btrfs cuz it had performed a snapshot only minutes before, and I could restore with "brtfs-restore /dev/root --time xxYyzz).... (I.e. whatever surprisingly good stuff it has to make people wanna use it as a primary or whatever?)... -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 7/4/2013 11:27 PM, Linda Walsh wrote:
Jeff Mahoney wrote:
On 7/4/13 10:10 AM, Jean Delvare wrote:
Hi Jeff,
Le Wednesday 03 July 2013 à 12:23 -0400, Jeff Mahoney a écrit :
So, I'd like to hear your stories. What's worked for you? What hasn't worked? What would you consider the pain points with using btrfs?
So, first and foremost, I'd need a statement that btrfs is now reliable enough (apparently you're hunting for exactly that) and also a comparison with ext4 proving that btrfs is better. And not just because it is new and cool and conceptually great - I want real-world facts. ---- And this is exactly the biggest problem with btrfs right now: perception. I understand where you're coming from, but this isn't the kind of response that's helpful. If the perception is to change, we need actual testing and corresponding bug reports if there are any.
I would tend to disagree, "50%". While having proof of "it's not bad because we have 24 thousand burgers served and only 3 bugs filed, Jean has a valid point -- why would I WANT to switch from something that has 124 million burger-serving hours and no complaints? Is it faster? Is it more reliable?
What's the fastest single-threaded input/output? Multi-threaded load? (compared to other FS's on same HW at same location on disk).
How about small random read/writes? deletes How is performance when fragmented?
Anything?
Where's the positive or things like "I did an accidental "mount /dev/root /mnt && rm -fr /mnt", but I was able to recover with btrfs cuz it had performed a snapshot only minutes before, and I could restore with "brtfs-restore /dev/root --time xxYyzz)....
(I.e. whatever surprisingly good stuff it has to make people wanna use it as a primary or whatever?)...
Good grief he ASKED for TESTERS. What was so hard to understand about that? You (either of you) don't want to test something? Fine, so don't test it. Other people will test it and then at some point you can enjoy the finished polished results of their testing. It doesn't require you to say "I'm not testing that because it's still in testing." Well, duh, yes it is, by definition. If he had said "We're switching the next version of opensuse to default to btrfs right now." there would be a reason to complain. He didn't say anything like that. -- bkw -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Am 03.07.2013 18:23, schrieb Jeff Mahoney:
I look forward to your feedback and the opportunity to improve btrfs for the 13.1 release and future releases.
Thanks!
-Jeff
Hi Jeff, I use BtrFS now for quite some time here on my small netbook with an SSD drive - which was the strongest argument to use BtrFS in the first place - still on openSUSE 12.1 and kernel 3.9.8. Root filesystem is 20 GB and is loaded with 15 GB pure data. My problem with BtrFS here on the Netbook is, that the snapshots created by YAST soon are eating up all free space and often during general update sessions (including newest stable kernels,XOrg, libre office etc. and keeping some old latest stable kernel generations) I have to drop manually a lot of snapshots to gain free space on the file system back. This is really annoying and from my point of view easy to solve. But I never had the time to go after and find some kind of switch to make the automatic deletion process more aggressive. When it happens I usually don't have the time to dig into it and simply use the snapper manually to delete snapshots. Maybe there is a solution in 12.2 or 12.3, but on that boxes I stayed with ext4 because of this initial problem. Another interesting thing I would be much interested in is generally compressed file systems (e.g. root fs with its huge number of well compressible files), but during my last installation sessions with 12.3 I still couldn't find an option for this in the installation process. This would have been another case of testing BtrFS again and get an advantage against ext4. Cheers Ralf -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
В Fri, 02 Aug 2013 01:05:07 +0200 "Dr. Ralf Czekalla" <ralf@czekalla.com> пишет:
My problem with BtrFS here on the Netbook is, that the snapshots created by YAST soon are eating up all free space and often during general update sessions (including newest stable kernels,XOrg, libre office etc. and keeping some old latest stable kernel generations) I have to drop manually a lot of snapshots to gain free space on the file system back. This is really annoying and from my point of view easy to solve.
But that's not really btrfs issue, is not it? I mean, you need to raise this problem in the right place to have it solved ... :) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 8/1/13 10:39 PM, Andrey Borzenkov wrote:
В Fri, 02 Aug 2013 01:05:07 +0200 "Dr. Ralf Czekalla" <ralf@czekalla.com> пишет:
My problem with BtrFS here on the Netbook is, that the snapshots created by YAST soon are eating up all free space and often during general update sessions (including newest stable kernels,XOrg, libre office etc. and keeping some old latest stable kernel generations) I have to drop manually a lot of snapshots to gain free space on the file system back. This is really annoying and from my point of view easy to solve.
But that's not really btrfs issue, is not it? I mean, you need to raise this problem in the right place to have it solved ... :)
Not purely a btrfs issue, but it is part of the user experience. Enough people have commented on it and we /have/ noticed. It's a matter of finding the right solution for it. One of the things on our radar is free space accounting in zypper. We currently assume that any removed files will release the space occupied by them - but that assumption isn't always valid when snapshots are in play. I can't tell you how many times I've had to suspend a 'zypper dup' when running Factory to remove snapshots in the background after the update runs out of space. Another option is automatic culling of snapshots based on some policy. Arvin, who's the engineer behind Snapper, would know more about that. My understanding is that the automatic functionality is improving rapidly. -Jeff -- Jeff Mahoney SUSE Labs
On 8/1/13 7:05 PM, Dr. Ralf Czekalla wrote:
Am 03.07.2013 18:23, schrieb Jeff Mahoney:
I look forward to your feedback and the opportunity to improve btrfs for the 13.1 release and future releases.
Thanks!
-Jeff
Hi Jeff,
I use BtrFS now for quite some time here on my small netbook with an SSD drive - which was the strongest argument to use BtrFS in the first place - still on openSUSE 12.1 and kernel 3.9.8. Root filesystem is 20 GB and is loaded with 15 GB pure data.
My problem with BtrFS here on the Netbook is, that the snapshots created by YAST soon are eating up all free space and often during general update sessions (including newest stable kernels,XOrg, libre office etc. and keeping some old latest stable kernel generations) I have to drop manually a lot of snapshots to gain free space on the file system back. This is really annoying and from my point of view easy to solve. But I never had the time to go after and find some kind of switch to make the automatic deletion process more aggressive. When it happens I usually don't have the time to dig into it and simply use the snapper manually to delete snapshots. Maybe there is a solution in 12.2 or 12.3, but on that boxes I stayed with ext4 because of this initial problem.
I've commented briefly on this in my response to Andrey's response to this post. It may be possible to disable the automatic snapshot functionality but TBH I've never investigated it.
Another interesting thing I would be much interested in is generally compressed file systems (e.g. root fs with its huge number of well compressible files), but during my last installation sessions with 12.3 I still couldn't find an option for this in the installation process. This would have been another case of testing BtrFS again and get an advantage against ext4.
I think this would still be an item for the long-term roadmap. There are still some rare and weird issues with compression that would lead me to still mark that feature as experimental. -Jeff -- Jeff Mahoney SUSE Labs
On 2013-08-02 T 06:41 -0400 Jeff Mahoney wrote:
On 8/1/13 7:05 PM, Dr. Ralf Czekalla wrote:
My problem with BtrFS here on the Netbook is, that the snapshots created by YAST soon are eating up all free space and often during general update sessions (including newest stable kernels,XOrg, libre office etc. and keeping some old latest stable kernel generations) I have to drop manually a lot of snapshots to gain free space on the file system back. This is really annoying and from my point of view easy to solve. But I never had the time to go after and find some kind of switch to make the automatic deletion process more aggressive. When it happens I usually don't have the time to dig into it and simply use the snapper manually to delete snapshots. Maybe there is a solution in 12.2 or 12.3, but on that boxes I stayed with ext4 because of this initial problem.
I've commented briefly on this in my response to Andrey's response to this post. It may be possible to disable the automatic snapshot functionality but TBH I've never investigated it.
There is a quick way to disable automated snapshots from zypper completely: zypper rm snapper-zypp-plugin I would not do this, though, but instead change the config options in "/etc/snapper/configs/root" to be more aggressive in removing snapshots. I personally meanwhile switched off TIMELINE based snapshots completly and only do manual and zypper based snapshots for "/". If you are short on diskspace or following factory closely, something like this can help (it will keep 8 pre/post snapshot pairs only): ---------------------------< snip >--------------------------- # snapper diff 10..11 /etc/snapper/configs/root --- /.snapshots/10/snapshot/etc/snapper/configs/root 2013-07-26 11:11:01.092720678 +0200 +++ /.snapshots/11/snapshot/etc/snapper/configs/root 2013-08-02 13:05:15.548336389 +0200 @@ -19,11 +19,11 @@ # limit for number cleanup NUMBER_MIN_AGE="1800" -NUMBER_LIMIT="100" +NUMBER_LIMIT="16" # create hourly snapshots -TIMELINE_CREATE="yes" +TIMELINE_CREATE="no" # cleanup hourly snapshots after some time TIMELINE_CLEANUP="yes" ---------------------------< snap >--------------------------- For more information, see "man snapper". HTH so long - MgE -- Matthias G. Eckermann Senior Product Manager SUSE® Linux Enterprise Phone: +49 30 44315731 Mobile: +49 179 2949448 E-Mail: mge@suse.com SUSE LINUX Products GmbH Maxfeldstraße 5 90409 Nürnberg Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Fri, Aug 02, 2013 at 01:12:57PM +0200, Matthias G. Eckermann wrote:
There is a quick way to disable automated snapshots from zypper completely:
zypper rm snapper-zypp-plugin
I would not do this, though, but instead change the config options in "/etc/snapper/configs/root" to be more aggressive in removing snapshots. I personally meanwhile switched off TIMELINE based snapshots completly and only do manual and zypper based snapshots for "/". If you are short on diskspace or following factory closely, something like this can help (it will keep 8 pre/post snapshot pairs only):
---------------------------< snip >--------------------------- # snapper diff 10..11 /etc/snapper/configs/root --- /.snapshots/10/snapshot/etc/snapper/configs/root 2013-07-26 11:11:01.092720678 +0200 +++ /.snapshots/11/snapshot/etc/snapper/configs/root 2013-08-02 13:05:15.548336389 +0200 @@ -19,11 +19,11 @@
# limit for number cleanup NUMBER_MIN_AGE="1800" -NUMBER_LIMIT="100" +NUMBER_LIMIT="16"
# create hourly snapshots -TIMELINE_CREATE="yes" +TIMELINE_CREATE="no"
# cleanup hourly snapshots after some time TIMELINE_CLEANUP="yes" ---------------------------< snap >---------------------------
For more information, see "man snapper".
Or better the new "snapper-configs". If not included on your system yet use http://snapper.io/manpages/snapper-configs.html. Regards, Arvin -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
participants (13)
-
Andrey Borzenkov -
Arvin Schnell -
Brian K. White -
Carlos E. R. -
Cristian Rodríguez -
David Sterba -
Dr. Ralf Czekalla -
Jean Delvare -
Jeff Mahoney -
Jeff Mahoney -
Linda Walsh -
Matthias G. Eckermann -
Takashi Iwai