>
> usr/lib/node_modules/node-gyp/gyp/pylib/gyp/MSVSVersion.py failed: No
> space left on device
>
> At subvol snapshot
> ERROR: rename o259-1095-0 -> myser/.bash_profile failed: No space left on
> device
>
> I have run this script many, many times and never seen err
eft on device
At subvol snapshot
ERROR: rename o259-1095-0 -> myser/.bash_profile failed: No space left on device
I have run this script many, many times and never seen errors like
this. There is plenty of room on the device:
# btrfs fi df /mnt/
Data, single: total=18.01GiB, used=16.53GiB
Syste
uring output to : Broken pipe
> WARNING: [send/receive] (send=/mnt/btrfs/ssd/_snapshots/system.20181016T2034,
> receive=/mnt/btrfs/backup) At subvol
> /mnt/btrfs/ssd/_snapshots/system.20181016T2034
> WARNING: [send/receive] (send=/mnt/btrfs/ssd/_snapshots/system.20181016T2034,
&
sd/_snapshots/system.20181016T2034,
receive=/mnt/btrfs/backup) At subvol system.20181016T2034
ERROR: rename o77417-5519-0 ->
lib/modules/4.18.0-0.bpo.1-amd64/kernel/drivers/watchdog/pcwd_pci.ko failed: No
space left on device
ERROR: Failed to send/receive btrfs subvolume:
/mnt/btrfs/ssd/_snapsho
On 10.11.2017 22:51 Chris Murphy wrote:
>> Combined with evidence that "No space left on device" during balance can
>> lead to various file corruption (we've witnessed it with MySQL), I'd day
>> btrfs balance is a dangerous operation and decision to use it should be
&
0 seconds.
> Use Ctrl-C to stop it.
> 10 9 8 7 6 5 4 3 2 1
> Starting balance without any filters.
> ERROR: error during balancing '/var/lib/lxd': No space left on device
> There may be more info in syslog - try dmesg | tail
OK I wonder if this is a bug in user space tool's e
7 6 5 4 3 2 1
Starting balance without any filters.
ERROR: error during balancing '/var/lib/lxd': No space left on device
There may be more info in syslog - try dmesg | tail
# btrfs fi usage /var/lib/lxd
Overall:
Device size: 846.26GiB
Device allocated:
ring balance. This array has been extended several times but this is the
>> first time I have seen any issues.
>>
>> Looking at the list archives, it seems that some others have had similar
>> problems. Has anyone found a solution or any recommendations?
>>
>> Th
seconds.
Use Ctrl-C to stop it.
10 9 8 7 6 5 4 3 2 1
Starting balance without any filters.
ERROR: error during balancing '/srv': No space left on device
There may be more info in syslog - try dmesg | tail
real8731m13.424s
user0m0.000s
sys 560m36.363s
# dmesg -c
(...)
[546228.
> first time I have seen any issues.
>
> Looking at the list archives, it seems that some others have had similar
> problems. Has anyone found a solution or any recommendations?
>
> Thanks,
>
> Ben
>
> Cannot remove device, no space left on device
> https://mar
?
> # btrfs balance start -v -dusage=0 /data
> Dumping filters: flags 0x1, state 0x0, force is off
> DATA (flags 0x2): balancing, usage=0
> ERROR: error during balancing '/data': No space left on device
> There may be more info in syslog - try dmesg | tail
> # uname -a
>
but this is the first time
I have seen any issues.
Looking at the list archives, it seems that some others have had similar
problems. Has anyone found a solution or any recommendations?
Thanks,
Ben
Cannot remove device, no space left on device
https://marc.info/?l=linux-btrfs=150684414519356=2
On 2017-10-31 23:18, Tomasz Chmielewski wrote:
On a different server, however, it failed badly:
# time btrfs balance start /srv
WARNING:
Full balance without filters requested. This operation is very
intense and takes potentially very long. It is recommended to
use the
On 2017-09-18 17:20, Tomasz Chmielewski wrote:
# df -h /var/lib/lxd
FWIW, standard (aka util-linux) df is effectively useless in a
situation
such as this, as it really doesn't give you the information you need
(it
can say you have lots of space available, but if btrfs has all of it
allocated
like to RMA this drive out of an abundance of caution. Doing
>> so requires me removing it from my raid10 array. However I am unable to
>> do so as it eventually errors out by saying there is no space left on
>> the device. I have 21 drives in a raid10 array. Totalling about 100TB
>>
Hi all,
I'm getting an error "No space left on device" on a VM in VirtualBox.
It started as I was trying to convert the .vdi to .img. I wanted to
shrink the size of the disk first and I followed the steps from here:
https://superuser.com/questions/529149/how-to-compact-virtualboxs-vdi
drive out of an abundance of caution. Doing
> so requires me removing it from my raid10 array. However I am unable to
> do so as it eventually errors out by saying there is no space left on
> the device. I have 21 drives in a raid10 array. Totalling about 100TB
> raw. I'm using around 28TB. So I should
filesystem is balanced fine. I'm on kernel 4.10
I also tried adding more space. I threw in another 4TB hard drive and
it added mostly fine. It took 3-4 tries at a balance before it was
fully balanced into the array. The same no space left on device error
occurred when adding the drive. But it did
> Consider the following case:
>
> - system admin runs btrfs balance on a filesystem with 100 GB free and
> assumes it is enough space to complete successfully
>
> - btrfs balance fails due to some bug with "No space left on device"
>
> - at the same time, a dat
On 2017-09-18 22:44, Peter Becker wrote:
i'm not sure if it would help, but maybe you could try adding an 8GB
(or more) USB flash drive to the pool and try to start balance.
if it works out, you can throw him out of the pool after that.
I really can't, it's an "online server".
But I've
i'm not sure if it would help, but maybe you could try adding an 8GB
(or more) USB flash drive to the pool and try to start balance.
if it works out, you can throw him out of the pool after that.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to
case:
- system admin runs btrfs balance on a filesystem with 100 GB free and
assumes it is enough space to complete successfully
- btrfs balance fails due to some bug with "No space left on device"
- at the same time, a database using this filesystem will fail with "No
space le
On Mon, Sep 18, 2017 at 11:20 AM, Tomasz Chmielewski wrote:
>>> # df -h /var/lib/lxd
>>>
>>> FWIW, standard (aka util-linux) df is effectively useless in a situation
>>> such as this, as it really doesn't give you the information you need (it
>>> can say you have lots of space
# df -h /var/lib/lxd
FWIW, standard (aka util-linux) df is effectively useless in a
situation
such as this, as it really doesn't give you the information you need
(it
can say you have lots of space available, but if btrfs has all of it
allocated into chunks, even if the chunks have space in
-v /var/lib/lxd -dusage=0 -musage=0
> [no chunks with 0 usage to balance]
>
>
> # time btrfs balance start -v /var/lib/lxd
> [...]
> ERROR: error during balancing '/var/lib/lxd': No space left on device
OK, that fails. Let's see what your unallocated space looks like,
below
to skip this
warning. The operation will start in 10 seconds.
Use Ctrl-C to stop it.
10 9 8 7 6 5 4 3 2 1
Starting balance without any filters.
ERROR: error during balancing '/var/lib/lxd': No space left on device
There may be more info in syslog - try dmesg | tail
real
On 07/20/2017 11:53 PM, Christoph Anton Mitterer wrote:
> On Thu, 2017-07-20 at 14:48 -0700, Omar Sandoval wrote:
> [...]
>
>>> I assume you'll take care to get that patch into stable kernels?
>>> Is this patch alone enough to recommend the Debian maintainers to
>>> include it into their 4.9 long
On Thu, Jul 20, 2017 at 11:53:16PM +0200, Christoph Anton Mitterer wrote:
> On Thu, 2017-07-20 at 14:48 -0700, Omar Sandoval wrote:
> > Just to be sure, did you explicitly write 0 to these?
> Nope... that seemed to have been the default value, i.e. I used
> sysctl(8) in read (and not set) mode
On Thu, 2017-07-20 at 14:48 -0700, Omar Sandoval wrote:
> Just to be sure, did you explicitly write 0 to these?
Nope... that seemed to have been the default value, i.e. I used
sysctl(8) in read (and not set) mode here.
> These sysctls are
> really confusing, see
On Thu, Jul 20, 2017 at 11:33:56PM +0200, Christoph Anton Mitterer wrote:
> On Thu, 2017-07-20 at 10:32 -0700, Omar Sandoval wrote:
> > If that doesn't work, could you please also try
> > https://patchwork.kernel.org/patch/9829593/?
>
> Okay, tried the patch now, applied upon:
> Linux
On Thu, 2017-07-20 at 10:32 -0700, Omar Sandoval wrote:
> If that doesn't work, could you please also try
> https://patchwork.kernel.org/patch/9829593/?
Okay, tried the patch now, applied upon:
Linux 4.12.0-trunk-amd64 #1 SMP Debian 4.12.2-1~exp1 (2017-07-18) x86_64
GNU/Linux
(that is the Debian
On Thu, Jul 20, 2017 at 10:28:15PM +0200, Christoph Anton Mitterer wrote:
> On Thu, 2017-07-20 at 11:14 -0700, Omar Sandoval wrote:
> > Yes, that's a safe enough workaround. It's a good idea to change the
> > parameters back after the copy.
> you mean even without having the fix, right?
Yes, even
On Thu, 2017-07-20 at 11:14 -0700, Omar Sandoval wrote:
> Yes, that's a safe enough workaround. It's a good idea to change the
> parameters back after the copy.
you mean even without having the fix, right?
So AFAIU, the bug doesn't really cause FS corruption, but just "false"
ENOSPC and these
On Thu, Jul 20, 2017 at 08:06:52PM +0200, Christoph Anton Mitterer wrote:
> On Thu, 2017-07-20 at 10:55 -0700, Omar Sandoval wrote:
> > Against 4.12 would be best, thanks!
> okay,.. but that will take a while to compile...
>
>
> in the meantime... do you know whether it's more or less safe to
On Thu, 2017-07-20 at 10:55 -0700, Omar Sandoval wrote:
> Against 4.12 would be best, thanks!
okay,.. but that will take a while to compile...
in the meantime... do you know whether it's more or less safe to use
the 4.9 kernel without any fix, when I change the parameters mentioned
before,
On Thu, Jul 20, 2017 at 07:48:24PM +0200, Christoph Anton Mitterer wrote:
> On Thu, 2017-07-20 at 10:32 -0700, Omar Sandoval wrote:
> > Could you try 4.12?
> Linux 4.12.0-trunk-amd64 #1 SMP Debian 4.12.2-1~exp1 (2017-07-18)
> x86_64 GNU/Linux
> from Debian experimental, doesn't fix the issue...
On Thu, 2017-07-20 at 10:32 -0700, Omar Sandoval wrote:
> Could you try 4.12?
Linux 4.12.0-trunk-amd64 #1 SMP Debian 4.12.2-1~exp1 (2017-07-18)
x86_64 GNU/Linux
from Debian experimental, doesn't fix the issue...
> If that doesn't work, could you please also try
>
On Thu, Jul 20, 2017 at 05:20:13PM +0200, Christoph Anton Mitterer wrote:
> On Thu, 2017-07-20 at 15:00 +, Martin Raiber wrote:
> > It would be interesting if lowering the dirty ratio is a viable
> > work-around (sysctl vm.dirty_background_bytes=314572800 && sysctl
> >
On Thu, 2017-07-20 at 15:00 +, Martin Raiber wrote:
> there are patches on this list/upstream which could fix this ( e.g.
> "fix
> delalloc accounting leak caused by u32 overflow"/"fix early ENOSPC
> due
> to delalloc").
mhh... it's a bit problematic to test these on that nodes...
> Do you
On Thu, 2017-07-20 at 15:00 +, Martin Raiber wrote:
> It would be interesting if lowering the dirty ratio is a viable
> work-around (sysctl vm.dirty_background_bytes=314572800 && sysctl
> vm.dirty_bytes=1258291200).
>
> Regards,
> Martin
I took away a trailing 0 for each of them... and then
Oh and I should add:
After such error, cp goes on copying (with other files)...
Same issue occurs when I do something like tar -cf - /media | tar -xf
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
a/security/PrivilegedExceptionAction.html': No space
left on device
cp: cannot create regular file
'/mnt/root/X/media/usr/share/doc/openjdk-8-jre-
headless/api/java/security/Provider.Service.html': No space left on
device
cp: cannot create regular file
'/mnt/root/X/media/usr/share/doc/openjdk-8-jre-
headless/api/ja
It did it again:
shrapnel share # touch test.txt
touch: cannot touch 'test.txt': No space left on device
shrapnel share # df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root35G 19G 15G 56% /
devtmpfs 10M 0 10M 0% /dev
tmpfs 3.2G 1.2M 3.2G 1
Dmarc is off, here's the output of the allocations: it's working
correctly right now, I'll update when it does it again.
/sys/fs/btrfs/7af2e65c-3935-4e0d-aa63-9ef6be991cb9/allocation/system/flags:2
/sys/fs/btrfs/7af2e65c-3935-4e0d-aa63-9ef6be991cb9/allocation/system/raid1/used_bytes:3948544
On Thu, Apr 27, 2017 at 10:46 AM, Gerard Saraber wrote:
> After a reboot, I found this in the logs:
> [ 322.510152] BTRFS info (device sdm): The free space cache file
> (36114966511616) is invalid. skip it
> [ 488.702570] btrfs_printk: 847 callbacks suppressed
>
>
>
> On
After a reboot, I found this in the logs:
[ 322.510152] BTRFS info (device sdm): The free space cache file
(36114966511616) is invalid. skip it
[ 488.702570] btrfs_printk: 847 callbacks suppressed
On Thu, Apr 27, 2017 at 10:18 AM, Gerard Saraber wrote:
> no snapshots and
no snapshots and no qgroups, just a straight up large volume.
shrapnel gerard-store # btrfs fi df /home/exports
Data, RAID1: total=20.93TiB, used=20.86TiB
System, RAID1: total=32.00MiB, used=3.73MiB
Metadata, RAID1: total=79.00GiB, used=61.10GiB
GlobalReserve, single: total=512.00MiB,
On Thu, 27 Apr 2017 08:52:30 -0500
Gerard Saraber wrote:
> I could just reboot the system and be fine for a week or so, but is
> there any way to diagnose this?
`btrfs fi df` for a start.
Also obligatory questions: do you have a lot of snapshots, and do you use
qgroups?
create directory 'gopro': No space left on device
^^ that error message pops up after 10-15 seconds.
I could just reboot the system and be fine for a week or so, but is
there any way to diagnose this?
Thanks!
-Gerard
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" i
Hi all
I recently submitted a bug report to launchpad (
https://bugs.launchpad.net/ubuntu/+source/btrfs-tools/+bug/1664013 ) but
I now found out about this mailing list, which may be a better place to
post.
Basically, whenever many files are created at high throughput in my
empty btrfs
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:
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
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
>
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
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
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
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
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
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 lac
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
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!
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
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
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
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
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,
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
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
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
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.
>>
>
>
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
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
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
>
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
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
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
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,
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
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
>
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 /`
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
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
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
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
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
>
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
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
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
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
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
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:
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]
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
On Tue, Aug 30, 2016 at 5:13 PM, Chris Murphy wrote:
> On Tue, Aug 30, 2016 at 4:22 AM, ojab // wrote:
>> On Mon, Aug 29, 2016 at 9:05 PM, Chris Murphy
>> wrote:
>>> On Mon, Aug 29, 2016 at 10:04 AM, ojab // wrote:
1 - 100 of 421 matches
Mail list logo