Hi Rich,
Le 18/06/2019 à 13:19, Chris Murphy a écrit :
> On Tue, Jun 18, 2019 at 4:23 PM Rich Turner wrote:
>>
>> tar: ./lib/modules/4.4.73-7-default/kernel/drivers/md/faulty.ko: Cannot
>> open: No space left on device
>
> If this really is a 4.4.73 based kernel, I
On Tue, Jun 18, 2019 at 4:23 PM Rich Turner wrote:
>
> tar: ./lib/modules/4.4.73-7-default/kernel/drivers/md/faulty.ko: Cannot open:
> No space left on device
If this really is a 4.4.73 based kernel, I expect the report is out of
scope for this list. There have been 109 subseque
Hi List,
I am attempting to extract a tar archive into a btrfs filesystem and more often
than not tar will fail with “No space left on device” error. I say “more often
than not” because sometimes the extraction completes successfully even though I
am following the same steps.
# mkfs.btrfs -f
Hello!
I have a problem with btrfs device.
Shows 355Gb free space.
Done scrub on that.
It shows that there is no space left on device.
Doing simple operations (mkdir, touch, find) are extremely slow.
Checking btrfsck show add_data_backref error (see below).
Do you think I could do : btrfs
On Wed, Mar 6, 2019 at 7:29 AM Michael Firth wrote:
>
> Hi,
>
> I have a BTRFS filesystem that seems to have become very ill. After 4 hours
> of being mounted, it will fail with every write attempt saying "No space left
> on device".
What program/process is trying
On Wed, 6 Mar 2019 at 16:53, Michael Firth wrote:
>
> Is there any way to get more debugging from what is going on?
Try mounting with enospc_debug.
> The system is running stock Debian 9 (Stretch). It was running their latest
> 4.9 kernel (Rev 4.9.144-3.1) when the problem first occurred. After
Hi,
I have a BTRFS filesystem that seems to have become very ill. After 4 hours of
being mounted, it will fail with every write attempt saying "No space left on
device".
Unmounting and remounting the filesystem clears the issue for another 4 hours
>From every check I have done
>
> 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 s
rt 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
OK I wonder if this is a bug in u
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
# btrfs fi usage /var/lib/lxd
Overall:
Device size: 846.26GiB
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?
>>
>> Thanks,
>>
>> Ben
>>
>
he 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 '/srv': No space left on device
There may be more info in syslog - try dmesg | tail
real8731m13.424s
user0m0.000s
sys
en 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&m
?
> # 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
> # un
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&m=15068441451
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
I have upgraded to kernel 4.13.8-1 and still cannot delete this disk.
I find it weird that I cannot remove a from my array. Especially on
one of the newest kernels available sourced straight from kernel.org
On Sun, Oct 1, 2017 at 4:57 AM, Duncan <1i5t5.dun...@cox.net> wrote:
> Adam Bahe posted on
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-virtualbox
Adam Bahe posted on Sun, 01 Oct 2017 02:48:19 -0500 as excerpted:
> Hello,
Hi, Just a user and list regular here, not a dev, but perhaps some of
this will be of help.
> I have a hard drive that is about a year old with some pending sectors
> on it. I'd like to RMA this drive out of an abundance
though my 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 dr
> 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 removed
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 m
min 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 left on device"
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 available, but if bt
# 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 th
tart -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 spac
ce' option 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
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 here
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 https://www.kernel.org/doc/Docume
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 4.12.0-trunk
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 happ
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 use
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, during
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...
Ok
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
> https://patchwork.kernel.org/pat
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
> > vm.dirty_bytes=1258291200
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 i
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 u
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
eadless/api/java/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
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
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
/sys/f
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 Thu, Apr 27, 2017 at 10:
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 qgroups, just a st
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, used=544.00K
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?
--
With respect,
Roman
ir: cannot 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
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 file
Hi guys!
After a week without experiencing the problem, I think we can mark this
problem as solved. I want to thanks all the devs on this list. You were
always very helpful. For anyone who is still experiencing the reported
problem, upgrade to kernel 4.7.3 and I think you will be fine :)
Best reg
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 la
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 sd
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
1 - 100 of 463 matches
Mail list logo
