[opensuse] btrfs has taken over
My system has been unusable for 15 minutes or so (and is still very slow). I suspect btrfs, it is showing at the top of top. The disk activity light is permanently on. Is there away to control when it does whatever it is doing? I fear I will have to re-install the system with a different filesystem for root. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 20.02.2017 16:17, Richmond wrote:
My system has been unusable for 15 minutes or so (and is still very slow). I suspect btrfs, it is showing at the top of top. The disk activity light is permanently on. Is there away to control when it does whatever it is doing? I fear I will have to re-install the system with a different filesystem for root.
First, boot a rescue image and check your filesystems for errors. If it's not that, you can ask btrfs for some statistics, maybe it's running out of internal space. Also make sure you have all patches installed, the latest kernel (4.4.46) contained a couple of bug fixes, I think. Regards, -- Aaron "Optimizer" Digulla a.k.a. Philmann Dark "It's not the universe that's limited, it's our imagination. Follow me and I'll show you something beyond the limits." http://blog.pdark.de/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am Montag, 20. Februar 2017, 15:17:01 CET schrieb Richmond:
My system has been unusable for 15 minutes or so (and is still very slow). I suspect btrfs, it is showing at the top of top. The disk activity light is permanently on.
http://bugzilla.opensuse.org/show_bug.cgi?id=1017461
Is there away to control when it does whatever it is doing?
I suspect it is rebalancing with quotas enable, check # btrfs balance status /
I fear I will have to re-install the system with a different filesystem for root.
No. You just have to disable quotas and quota support in snapper: # btrfs quota disable / # snapper set-config QGROUP= NUMBER_LIMIT=10 NUMBER_LIMIT_IMPORTANT=10 HTH Jan -- A conservative is a worshipper of dead radicals. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Thanks for the replies. It's too late unfortunately. The system was unusable for an hour or so. Afterwards I lost patience and re-installed with ext4. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/20/2017 01:24 PM, Richmond wrote:
Thanks for the replies. It's too late unfortunately. The system was unusable for an hour or so. Afterwards I lost patience and re-installed with ext4.
Good solution. One additional question: Was the drive on an SSD? -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
John Andersen wrote:
On 02/20/2017 01:24 PM, Richmond wrote:
Thanks for the replies. It's too late unfortunately. The system was unusable for an hour or so. Afterwards I lost patience and re-installed with ext4.
Good solution. One additional question: Was the drive on an SSD?
No. It's not a very big drive though by today's standards. So I only have 20G for the root file system. 51G for /home. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 21 February 2017 at 12:22, John Andersen <jsamyth@gmail.com> wrote:
Good solution. One additional question: Was the drive on an SSD?
I've had issues with fstrim hanging the computer with an SSD, regardless of whether I used ext4 or btrfs (it's actually slightly better for me with btrfs). Not sure how exactly to fix it though, the issue isn't as severe these days, but it's still somewhat noticeable. -- - Karl Cheng (Qantas94Heavy) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On February 21, 2017 3:24:47 AM PST, Karl Cheng <qantas94heavy@gmail.com> wrote:
On 21 February 2017 at 12:22, John Andersen <jsamyth@gmail.com> wrote:
Good solution. One additional question: Was the drive on an SSD?
I've had issues with fstrim hanging the computer with an SSD, regardless of whether I used ext4 or btrfs (it's actually slightly better for me with btrfs). Not sure how exactly to fix it though, the issue isn't as severe these days, but it's still somewhat noticeable.
Yes, which is exactly why I asked if the drive was an SSD. I've removed the discard option from the fstab in favor of systemd fstrim.timer option as widly recommended, but I still get occasional bouts of unexpected debilitating disk activity that I can only attribute to fstrim. The drive has no BTRFS partitions. I wonder how well fstrim has been vetted in 42.2. Is there any way to know if it is working properly? -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/21/2017 09:33 AM, John Andersen wrote:
I still get occasional bouts of unexpected debilitating disk activity that I can only attribute to fstrim.
I should note that I have no real reason to calim it is fstrim, its just a hunch. Fstrim run manually does not appear to take anywhere near as long - maybe 45 seconds, nor is it debilitating. (Machine remains rsponsive).
poulsbo:~ # fstrim -a -v /home: 271.3 GiB (291247837184 bytes) trimmed /raid: 30.8 GiB (33058480128 bytes) trimmed
Its too bad that fstrim does not report actual results. (If you run it again it will report the exact same results - as mentioned in the man page). -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/21/2017 09:33 AM, John Andersen wrote:
I still get occasional bouts of unexpected debilitating disk activity that I can only attribute to fstrim. I should note that I have no real reason to calim it is fstrim, its just a hunch. Fstrim run manually does not appear to take anywhere near as long - maybe 45 seconds, nor is it debilitating. (Machine remains rsponsive).
From the linux raid mailing list, I gather there is a still-active
On 21/02/17 18:08, John Andersen wrote: problem with large trims. Basically, what happens is that user-space issues a trim of maybe several megs. Somewhere in the block layer it gets broken up into thousands of trims of say 4K each. And further down the block layer before it goes to the device, these trims are not recombined back into one large trim. So the i/o bus to the device gets flooded with small trims when it needn't be. This is being addressed, but it's a slow job ... not saying it's the problem you're seeing. Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/21/2017 11:38 AM, Wols Lists wrote:
This is being addressed, but it's a slow job ... not saying it's the problem you're seeing.
Sounds exactly like what I'm seeing. Often this occurs after closing a some application that uses large files. (Big images or movies - Vmware VM storage 2gig chunks, etc). But I would not expect this to do this on its own, disrupting my work, since I've remove the discard option on the partition, and have fstrim scheduled for sunday afternoon. http://www.linux-magazine.com/Issues/2016/187/SSD-tuning Somewhat dated: https://thunk.org/tytso/blog/2009/02/22/should-filesystems-be-optimized-for-... Newer post by Ted Ts'o on this: https://forums.freebsd.org/threads/56951/#post-328912 This post's *second paragraph* sounds a lot like what I am experiencing. And if so, it suggests that there is some trim taking place at times *not governed* by fstrim.timer. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (6)
-
Aaron Digulla -
Jan Ritzerfeld -
John Andersen -
Karl Cheng -
Richmond -
Wols Lists