Hi Josef,
Em qui, 2016-09-22 às 13:49 -0400, Josef Bacik escreveu:
> That patch fixed a problem where we would screw up the ENOSPC
> accounting, and
> would slowly leak space into one of the counters. So eventually (or
> often in
> your case) you'd hit ENOSPC, but have plenty of space available
On 09/22/2016 01:06 PM, Ronan Arraes Jardim Chagas wrote:
Hi Josef,
Em qui, 2016-09-22 às 10:39 -0400, Josef Bacik escreveu:
This is what fixed it. I thought it was in 4.7 which is why I
started paying
attention, but I guess I was wrong. Glad your problem is
resolved. Thanks,
Do you have a
Hi Josef,
Em qui, 2016-09-22 às 10:39 -0400, Josef Bacik escreveu:
> This is what fixed it. I thought it was in 4.7 which is why I
> started paying
> attention, but I guess I was wrong. Glad your problem is
> resolved. Thanks,
Do you have any explanations why the problem solved by the patch w
On 09/22/2016 10:03 AM, Ronan Arraes Jardim Chagas wrote:
Em qui, 2016-09-22 às 09:41 -0400, Austin S. Hemmelgarn escreveu:
Most likely the kernel upgrade fixed things. It's possible that the
large allocation is impacting something and making it work, but I
don't
think that that is very likely.
Em qui, 2016-09-22 às 09:41 -0400, Austin S. Hemmelgarn escreveu:
> Most likely the kernel upgrade fixed things. It's possible that the
> large allocation is impacting something and making it work, but I
> don't
> think that that is very likely.
The patches related to btrfs I could find in kern
On 2016-09-22 09:20, Ronan Arraes Jardim Chagas wrote:
Guys,
Something very strange happened. I have not seen the problem since
Monday, which is pretty much the first time ever I work more than 3
days without seeing it.
Ok, it can be a coincidence. Notice that I did not change anything
related
On 9/18/16 10:38 PM, Wang Xiaoguang wrote:
> hi,
>
> On 09/14/2016 10:25 PM, Jeff Mahoney wrote:
>> On 9/13/16 10:24 PM, Josef Bacik wrote:
>>> On 09/08/2016 07:02 PM, Jeff Mahoney wrote:
On 9/8/16 2:49 PM, Jeff Mahoney wrote:
> On 9/8/16 2:24 PM, Ronan Arraes Jardim Chagas wrote:
>>
Guys,
Something very strange happened. I have not seen the problem since
Monday, which is pretty much the first time ever I work more than 3
days without seeing it.
Ok, it can be a coincidence. Notice that I did not change anything
related to my work behavior. However, I did do two things:
_ Upd
hi,
On 09/14/2016 10:25 PM, Jeff Mahoney wrote:
On 9/13/16 10:24 PM, Josef Bacik wrote:
On 09/08/2016 07:02 PM, Jeff Mahoney wrote:
On 9/8/16 2:49 PM, Jeff Mahoney wrote:
On 9/8/16 2:24 PM, Ronan Arraes Jardim Chagas wrote:
Hi all!
Em Seg, 2016-09-05 às 16:49 +0800, Qu Wenruo escreveu:
Jus
Hi Chris,
Em Qua, 2016-09-14 às 16:25 -0600, Chris Murphy escreveu:
> All I can think of is the file system has gotten into a unique state
> through a combination of events. I'm still suspicious that qgroups is
> contributing to the problem even after being disabled. The workload
> you're talking
All I can think of is the file system has gotten into a unique state
through a combination of events. I'm still suspicious that qgroups is
contributing to the problem even after being disabled. The workload
you're talking about is completely ordinary and trivial.
The openSUSE layout is basically i
Hi guys,
The problem happened again, but now it was way more serious. I was
doing a big Tumbleweed update (4680 packages) and I got the ENOSPC
during the update. To avoid being left with a broken system, as it has
already happened in the past, I, unfortunately, needed to delete data
that I really
Hi Josef,
Em Ter, 2016-09-13 às 17:01 -0400, Josef Bacik escreveu:
> I just started paying attention to this, the last kernel I saw you
> were running
> was 4.7. Have you tried a recent kernel, like chris's tree?
>
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git
> for-l
On 9/13/16 10:24 PM, Josef Bacik wrote:
> On 09/08/2016 07:02 PM, Jeff Mahoney wrote:
>> On 9/8/16 2:49 PM, Jeff Mahoney wrote:
>>> On 9/8/16 2:24 PM, Ronan Arraes Jardim Chagas wrote:
Hi all!
Em Seg, 2016-09-05 às 16:49 +0800, Qu Wenruo escreveu:
> Just like what Wang has mentio
On 09/13/2016 04:49 PM, Ronan Arraes Jardim Chagas wrote:
Hi guys,
One more time I saw the problem. It begins to happen on a daily basis
now. Unfortunately the `enospc_debug` flag did not help. I did not see
any new information in the logs. This time, only a hard reset worked. I
could not even r
Hi guys,
One more time I saw the problem. It begins to happen on a daily basis
now. Unfortunately the `enospc_debug` flag did not help. I did not see
any new information in the logs. This time, only a hard reset worked. I
could not even reboot using gnome panel.
Best regards,
Ronan Arraes
--
To u
On 09/08/2016 07:02 PM, Jeff Mahoney wrote:
On 9/8/16 2:49 PM, Jeff Mahoney wrote:
On 9/8/16 2:24 PM, Ronan Arraes Jardim Chagas wrote:
Hi all!
Em Seg, 2016-09-05 às 16:49 +0800, Qu Wenruo escreveu:
Just like what Wang has mentioned, would you please paste all the
output
of the contents of /s
Hi!
Em Ter, 2016-09-13 às 11:17 +0800, Wang Xiaoguang escreveu:
> It maybe a irrelevant question, but do you have compression enabled?
>
> Regards,
> Xiaoguang Wang
No, I do not have compression enabled. I'm using openSUSE's default
configuration.
By the way, I was wrongly mounting the filesyst
hello,
On 08/13/2016 01:36 AM, Ronan Arraes Jardim Chagas wrote:
Hi guys,
I'm facing a daily problem with BTRFS. Almost everyday, I get the
message "No space left on device". Sometimes I can recover by balancing
the system but sometimes even balancing does not work due to the lack
of space. In
On 9/8/16 2:49 PM, Jeff Mahoney wrote:
> On 9/8/16 2:24 PM, Ronan Arraes Jardim Chagas wrote:
>> Hi all!
>>
>> Em Seg, 2016-09-05 às 16:49 +0800, Qu Wenruo escreveu:
>>> Just like what Wang has mentioned, would you please paste all the
>>> output
>>> of the contents of /sys/fs/btrfs//allocation?
>
On 9/8/16 2:24 PM, Ronan Arraes Jardim Chagas wrote:
> Hi all!
>
> Em Seg, 2016-09-05 às 16:49 +0800, Qu Wenruo escreveu:
>> Just like what Wang has mentioned, would you please paste all the
>> output
>> of the contents of /sys/fs/btrfs//allocation?
>>
>> It's recommended to use "grep . -IR " to
Hi all!
Em Seg, 2016-09-05 às 16:49 +0800, Qu Wenruo escreveu:
> Just like what Wang has mentioned, would you please paste all the
> output
> of the contents of /sys/fs/btrfs//allocation?
>
> It's recommended to use "grep . -IR " to get all the data as
> it
> will show the file name.
So, one m
Just like what Wang has mentioned, would you please paste all the output
of the contents of /sys/fs/btrfs//allocation?
It's recommended to use "grep . -IR " to get all the data as it
will show the file name.
Thanks,
Qu
At 09/03/2016 03:25 AM, Ronan Arraes Jardim Chagas wrote:
Hi guys!
Jeff
On Fri, Sep 2, 2016 at 9:47 PM, Ronan Arraes Jardim Chagas
wrote:
> Hi Chris,
>
> Em Sex, 2016-09-02 às 21:41 -0600, Chris Murphy escreveu:
>> I suggest removing the hardware, and the proprietary driver, and
>> retest the system with the existing Tumbleweed 4.7.0 kernel; and if
>> that still fails
Hi Chris,
Em Sex, 2016-09-02 às 21:41 -0600, Chris Murphy escreveu:
> I suggest removing the hardware, and the proprietary driver, and
> retest the system with the existing Tumbleweed 4.7.0 kernel; and if
> that still fails, then try the Leap 4.4 kernel.
>
> Proprietary kernels can do all kinds o
On Fri, Sep 2, 2016 at 8:47 PM, Ronan Arraes Jardim Chagas
wrote:
> Hi guys!
>
> Em Sex, 2016-09-02 às 16:39 -0600, Chris Murphy escreveu:
>> Worth a shot, considering the opensuse/SLE 4.4 kernel has a shittonne
>> of backports. It seems unlikely to me opensuse intends to not support
>> your hardw
Hi guys!
Em Sex, 2016-09-02 às 16:39 -0600, Chris Murphy escreveu:
> Worth a shot, considering the opensuse/SLE 4.4 kernel has a shittonne
> of backports. It seems unlikely to me opensuse intends to not support
> your hardware (skylake?)
Actually it is a peripheral we use to program embedded syst
On Fri, Sep 2, 2016 at 4:13 PM, Ronan Arraes Jardim Chagas
wrote:
> Hi!
>
> Em Sex, 2016-09-02 às 15:34 -0600, Chris Murphy escreveu:
>> Except for your software build case, I have about the same workload
>> you have with two machines, one SSD one HDD, using 4.7.0 for a month,
>> and then 4.7.2 fo
Hi!
Em Sex, 2016-09-02 às 15:34 -0600, Chris Murphy escreveu:
> Except for your software build case, I have about the same workload
> you have with two machines, one SSD one HDD, using 4.7.0 for a month,
> and then 4.7.2 for the last week. I haven't had any enospc on these
> two systems.
>
> I th
On Fri, Sep 2, 2016 at 1:56 PM, Ronan Arraes Jardim Chagas
wrote:
> Hi again guys!
>
> After I rebooted the computer, I still can't run balance on metatada:
Except for your software build case, I have about the same workload
you have with two machines, one SSD one HDD, using 4.7.0 for a month,
an
Hi again guys!
After I rebooted the computer, I still can't run balance on metatada:
btrfs balance start -musage=1 /
ERROR: error during balancing '/': No space left on device
There may be more info in syslog - try dmesg | tail
dmesg shows:
[ 2022.530285] BTRFS info (device sda6): relocating bl
Hi guys!
Jeff was right. I had the problem again today and quotas are disabled
now. I couldn't get any useful message in log this time. Look at the
metadata:
btrfs fi usage /
Overall:
Device size: 1.26TiB
Device allocated: 43.07GiB
Device unallocated:
On 9/2/16 11:20 AM, Ronan Arraes Jardim Chagas wrote:
> Hi Jeff,
>
> Em Sex, 2016-09-02 às 10:48 -0400, Jeff Mahoney escreveu:
>> Sorry, I miscommunicated there. The WARN_ON is annoying. It's the
>> underlying issue that's causing you to lose work that is the one that
>> concerns me.
>>
>
> O
Hi Jeff,
Em Sex, 2016-09-02 às 10:48 -0400, Jeff Mahoney escreveu:
> Sorry, I miscommunicated there. The WARN_ON is annoying. It's the
> underlying issue that's causing you to lose work that is the one that
> concerns me.
>
Oh, OK, I see, sorry about that :)
Thus, if disabling quotas does not
On 9/2/16 10:43 AM, Ronan Arraes Jardim Chagas wrote:
> Hi Jeff,
>
> Em Sex, 2016-09-02 às 10:26 -0400, Jeff Mahoney escreveu:
>> I explained what I think Ronan's issue is in another part of the
>> thread
>> just now. I don't think that's a severe issue at
>> all. Annoying? Sure,
>> but I'm mor
Hi Jeff,
Em Sex, 2016-09-02 às 10:26 -0400, Jeff Mahoney escreveu:
> I explained what I think Ronan's issue is in another part of the
> thread
> just now. I don't think that's a severe issue at
> all. Annoying? Sure,
> but I'm more concerned with the underlying ENOSPC issue. Without
> more
> i
On 9/1/16 8:12 PM, Chris Murphy wrote:
> On Thu, Sep 1, 2016 at 12:47 PM, Austin S. Hemmelgarn
> wrote:
>
>
>> 2. Snapper's default snapshot creation configuration is absolutely
>> pathological in nature, generating insane amounts of background resource
>> usage and taking up huge amounts of spa
On 8/31/16 4:49 PM, Ronan Arraes Jardim Chagas wrote:
> Hi guys!
>
> And the problem happened again. This time, I was only using Mozilla
> Firefox. I could get the very first message after the error. I hope it
> brings more information:
Ok, so I think this is a race that can happen when one threa
At 09/01/2016 05:44 AM, Chris Murphy wrote:
On Wed, Aug 31, 2016 at 2:49 PM, Ronan Arraes Jardim Chagas
wrote:
Hi guys!
And the problem happened again. This time, I was only using Mozilla
Firefox. I could get the very first message after the error. I hope it
brings more information:
[28039.
On Thu, Sep 1, 2016 at 12:47 PM, Austin S. Hemmelgarn
wrote:
> 2. Snapper's default snapshot creation configuration is absolutely
> pathological in nature, generating insane amounts of background resource
> usage and taking up huge amounts of space. If this were changed, you would
> be a lot le
On Thu, Sep 1, 2016 at 7:21 AM, Austin S. Hemmelgarn
wrote:
> Yes, you can just run `btrfs quota disable /` and it should work. This
> ironically reiterates that one of the bigger problems with BTRFS is that
> distros are enabling unstable and known broken features by default on
> install. I wa
Hi Jeff,
Em Qui, 2016-09-01 às 13:12 -0400, Jeff Mahoney escreveu:
> It's not. We use qgroups because that's the only way we can track
> how
> much space each subvolume is using, regardless of whether anyone
> wants
> to do enforcement. When it's working properly, snapper can make use
> of
> tha
On Thu, Sep 1, 2016 at 11:12 AM, Jeff Mahoney wrote:
> On 9/1/16 1:04 PM, Austin S. Hemmelgarn wrote:
>> On 2016-09-01 12:34, Ronan Arraes Jardim Chagas wrote:
>>> Em Qui, 2016-09-01 às 09:21 -0400, Austin S. Hemmelgarn escreveu:
Yes, you can just run `btrfs quota disable /` and it should
>>>
On 2016-09-01 13:12, Jeff Mahoney wrote:
On 9/1/16 1:04 PM, Austin S. Hemmelgarn wrote:
On 2016-09-01 12:34, Ronan Arraes Jardim Chagas wrote:
Em Qui, 2016-09-01 às 09:21 -0400, Austin S. Hemmelgarn escreveu:
Yes, you can just run `btrfs quota disable /` and it should
work. This
ironically re
On 9/1/16 1:04 PM, Austin S. Hemmelgarn wrote:
> On 2016-09-01 12:34, Ronan Arraes Jardim Chagas wrote:
>> Em Qui, 2016-09-01 às 09:21 -0400, Austin S. Hemmelgarn escreveu:
>>> Yes, you can just run `btrfs quota disable /` and it should
>>> work. This
>>> ironically reiterates that one of the bigg
On 9/1/16 1:39 PM, Ronan Arraes Jardim Chagas wrote:
> Hi Jeff,
>
> Em Qui, 2016-09-01 às 13:12 -0400, Jeff Mahoney escreveu:
>> It's not. We use qgroups because that's the only way we can track
>> how
>> much space each subvolume is using, regardless of whether anyone
>> wants
>> to do enforceme
Hi Jeff,
Em Qui, 2016-09-01 às 13:43 -0400, Jeff Mahoney escreveu:
> Absolutely. It doesn't affect the ability to take, retain, or
> recover
> using snapshots. It only affects the ability to see how much space a
> particular snapshot is using on disk, both from the user wanting to
> know
> and s
On 2016-09-01 12:34, Ronan Arraes Jardim Chagas wrote:
Em Qui, 2016-09-01 às 09:21 -0400, Austin S. Hemmelgarn escreveu:
Yes, you can just run `btrfs quota disable /` and it should
work. This
ironically reiterates that one of the bigger problems with BTRFS is
that
distros are enabling unstable
Em Qui, 2016-09-01 às 09:21 -0400, Austin S. Hemmelgarn escreveu:
> Yes, you can just run `btrfs quota disable /` and it should
> work. This
> ironically reiterates that one of the bigger problems with BTRFS is
> that
> distros are enabling unstable and known broken features by default
> on
> i
On 2016-09-01 08:57, Ronan Arraes Jardim Chagas wrote:
Hi!
Em Qua, 2016-08-31 às 17:09 -0600, Chris Murphy escreveu:
OK so Ronan, I'm gonna guess the simplest work around for your
problem
is to disable quota support, and see if the problem happens again.
Look at the output of the command pro
Hi!
Em Qua, 2016-08-31 às 17:09 -0600, Chris Murphy escreveu:
> OK so Ronan, I'm gonna guess the simplest work around for your
> problem
> is to disable quota support, and see if the problem happens again.
>
Look at the output of the command proposed by Jeff:
btrfs qgroup show /
qgroupid
On Wed, Aug 31, 2016 at 5:03 PM, Jeff Mahoney wrote:
> On 8/31/16 6:58 PM, Chris Murphy wrote:
> Does Ronan's call trace showing
>> /fs/btrfs/qgroup.c:2667
>>> btrfs_qgroup_free_meta implicate qgroups as a possible source of his
>>> problem? That trace would only happen if quotas were enabled, r
On 8/31/16 6:58 PM, Chris Murphy wrote:
> On Wed, Aug 31, 2016 at 4:47 PM, Jeff Mahoney wrote:
>> On 8/31/16 5:48 PM, Chris Murphy wrote:
>>> OK it looks like with -w flag I can get a reliable indication of
>>> whether quota is enabled or not:
>>>
>>> [root@f24s ~]# btrfs quota enable /mnt/0
>>> [
On Wed, Aug 31, 2016 at 4:47 PM, Jeff Mahoney wrote:
> On 8/31/16 5:48 PM, Chris Murphy wrote:
>> OK it looks like with -w flag I can get a reliable indication of
>> whether quota is enabled or not:
>>
>> [root@f24s ~]# btrfs quota enable /mnt/0
>> [root@f24s ~]# btrfs quota rescan -w /mnt/0
>> qu
On 8/31/16 5:48 PM, Chris Murphy wrote:
> OK it looks like with -w flag I can get a reliable indication of
> whether quota is enabled or not:
>
> [root@f24s ~]# btrfs quota enable /mnt/0
> [root@f24s ~]# btrfs quota rescan -w /mnt/0
> quota rescan started
> [root@f24s ~]# btrfs quota disable /mnt/
OK it looks like with -w flag I can get a reliable indication of
whether quota is enabled or not:
[root@f24s ~]# btrfs quota enable /mnt/0
[root@f24s ~]# btrfs quota rescan -w /mnt/0
quota rescan started
[root@f24s ~]# btrfs quota disable /mnt/0
[root@f24s ~]# btrfs quota rescan -w /mnt/0
ERROR: q
On Wed, Aug 31, 2016 at 2:49 PM, Ronan Arraes Jardim Chagas
wrote:
> Hi guys!
>
> And the problem happened again. This time, I was only using Mozilla
> Firefox. I could get the very first message after the error. I hope it
> brings more information:
>
> [28039.672199] [ cut here ]-
Hi guys!
And the problem happened again. This time, I was only using Mozilla
Firefox. I could get the very first message after the error. I hope it
brings more information:
[28039.672199] [ cut here ]
[28039.672253] WARNING: CPU: 3 PID: 31800 at ../fs/btrfs/qgroup.c:2667
b
Em Ter, 2016-08-30 às 10:44 -0600, Chris Murphy escreveu:
> It sounds related to read-only snapshots to me. I wonder if this
> system has something busy that's writing to a file, database, even
> maybe something just spamming journald, and then there's a read-only
> snapshot during the write, which
On Tue, Aug 30, 2016 at 6:50 AM, Ronan Arraes Jardim Chagas
wrote:
> Hi!
>
> Em Ter, 2016-08-30 às 10:12 +0800, Wang Xiaoguang escreveu:
>> For metadata, "bytes_may_use" is about 80GB, it's very big,
>> I think this value is very abnormal.
>>
>> So this explains why you have huge unallocated space
Hi!
Em Ter, 2016-08-30 às 10:12 +0800, Wang Xiaoguang escreveu:
> For metadata, "bytes_may_use" is about 80GB, it's very big,
> I think this value is very abnormal.
>
> So this explains why you have huge unallocated space, you still
> get ENOSPC error. In kernel btrfs, there is a function
> shoul
hello,
On 08/29/2016 11:52 PM, Ronan Arraes Jardim Chagas wrote:
Hi guys,
I just have the problem again. Now, it happens during the lunch time
when the machine was idle. Only the system processes were running. It
was not the first time that I saw this problem just after lunch when
the machine s
On 8/29/16 11:52 AM, Ronan Arraes Jardim Chagas wrote:
> Hi guys,
>
> I just have the problem again. Now, it happens during the lunch time
> when the machine was idle. Only the system processes were running. It
> was not the first time that I saw this problem just after lunch when
> the machine st
Hi guys,
I just have the problem again. Now, it happens during the lunch time
when the machine was idle. Only the system processes were running. It
was not the first time that I saw this problem just after lunch when
the machine stayed idle for a long period (+- 1h).
Here is the information requ
Hi!
Em Seg, 2016-08-29 às 20:12 +0800, Wang Xiaoguang escreveu:
> When strange ENOSPC errors occur, I think "btrfs fi usage"
> or "btrfs di df" do not help too much. Their output do not
> reflect btrfs kernel current status :)
>
> Would you please provide attribute files' values in
> /sys/fs/btr
hello,
On 08/13/2016 01:36 AM, Ronan Arraes Jardim Chagas wrote:
Hi guys,
I'm facing a daily problem with BTRFS. Almost everyday, I get the
message "No space left on device". Sometimes I can recover by balancing
the system but sometimes even balancing does not work due to the lack
of space. In
hi,
On Thu, Aug 25, 2016 at 05:56:18PM -0600, Chris Murphy wrote:
> Anyway it's a known problem, I don't think it's fixed still. There's a
> lot of enospc work in 4.8 so eventually it'll make sense to give it a
> shot with that kernel.
assuming that I'm willing to try that, will a successful reba
On Thu, Aug 25, 2016 at 9:58 AM, Lutz Vieweg wrote:
> On 08/16/2016 01:24 AM, Chris Murphy wrote:
>>
>> On Mon, Aug 15, 2016 at 5:12 PM, Ronan Chagas wrote:
>>>
>>> It happened again. The computer was completely unusable. The only useful
>>> message I saw was this one:
>>>
>>> http://img.ctrlv.in
On 08/16/2016 01:24 AM, Chris Murphy wrote:
On Mon, Aug 15, 2016 at 5:12 PM, Ronan Chagas wrote:
It happened again. The computer was completely unusable. The only useful
message I saw was this one:
http://img.ctrlv.in/img/16/08/16/57b24b0bb2243.jpg
Looks similar to this:
https://lkml.org/lkm
On 8/22/16 5:04 PM, Ronan Arraes Jardim Chagas wrote:
> Em Seg, 2016-08-22 às 14:49 -0600, Chris Murphy escreveu:
>> This is really weird. I'm running 4.7.0 (Fedora) and I'm not
>> experiencing problems, let alone this. What is this kernel's
>> provenance? Is it a plain mainline 4.7.0 that you buil
Em Seg, 2016-08-22 às 14:49 -0600, Chris Murphy escreveu:
> This is really weird. I'm running 4.7.0 (Fedora) and I'm not
> experiencing problems, let alone this. What is this kernel's
> provenance? Is it a plain mainline 4.7.0 that you built? I'm not
> really sure what to recommend except maybe goi
On Mon, Aug 22, 2016 at 2:39 PM, Ronan Arraes Jardim Chagas
wrote:
> The same thing just happened again! And now it was also fixed
> automatically, but now I have:
>
> Metadata,DUP: Size:33.50GiB, Used:812.78MiB
This is really weird. I'm running 4.7.0 (Fedora) and I'm not
experiencing problems, l
The same thing just happened again! And now it was also fixed
automatically, but now I have:
Metadata,DUP: Size:33.50GiB, Used:812.78MiB
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vg
New information guys! I formatted using the latest Tumbleweed snapshot
(btrfs-progs v4.7+20160729) and I still have the same problem.
I notice two things. First, when I see the "No space left on device",
it is fixed when the Metadata space increases **a lot**. For example,
when the error first occ
Em Seg, 2016-08-15 às 17:24 -0600, Chris Murphy escreveu:
> On Mon, Aug 15, 2016 at 5:12 PM, Ronan Chagas
> wrote:
> >
> > Hi guys!
> >
> > It happened again. The computer was completely unusable. The only
> > useful
> > message I saw was this one:
> >
> > http://img.ctrlv.in/img/16/08/16/57b24
On Mon, Aug 15, 2016 at 5:12 PM, Ronan Chagas wrote:
> Hi guys!
>
> It happened again. The computer was completely unusable. The only useful
> message I saw was this one:
>
> http://img.ctrlv.in/img/16/08/16/57b24b0bb2243.jpg
>
> Does it help?
>
> I decided to format and reinstall tomorrow. This i
On Fri, Aug 12, 2016 at 1:37 PM, Chris Murphy wrote:
> On Fri, Aug 12, 2016 at 1:00 PM, Ronan Arraes Jardim Chagas
> wrote:
>
> d. Run journalctl -f from a 2nd computer.
Hopefully it's obvious I mean run journalctl -f on the affected
computer remotely via ssh.
>
>> Do you
>> think that if I re
On Fri, Aug 12, 2016 at 1:00 PM, Ronan Arraes Jardim Chagas
wrote:
> Em Sex, 2016-08-12 às 12:02 -0600, Chris Murphy escreveu:
>> Tons of unallocated space. What kernel messages do you get for the
>> enospc? It sounds like this will be one of the mystery -28 error file
>> systems. So far as I reca
Em Sex, 2016-08-12 às 12:02 -0600, Chris Murphy escreveu:
> Tons of unallocated space. What kernel messages do you get for the
> enospc? It sounds like this will be one of the mystery -28 error file
> systems. So far as I recall the only work around is recreating the
> file system. There are two ad
On Fri, Aug 12, 2016 at 11:36 AM, Ronan Arraes Jardim Chagas
wrote:
> Hi guys,
>
> I'm facing a daily problem with BTRFS. Almost everyday, I get the
> message "No space left on device". Sometimes I can recover by balancing
> the system but sometimes even balancing does not work due to the lack
> o
80 matches
Mail list logo
