es across BTRFS subvolume boundaries.
--
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup
signature.asc
Description: This is a digitally signed message part.
Am Dienstag, 24. Juli 2018, 21:46:14 CEST schrieb Duncan:
> Andrei Borzenkov posted on Tue, 24 Jul 2018 20:53:15 +0300 as excerpted:
> > 24.07.2018 15:16, Marc Joliet пишет:
> >> Hi list,
> >>
> >> (Preemptive note: this was with btrfs-progs 4.15.1, I have sin
bly went wrong, or any similar experience
to speak of?
Greetings
--
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup
signature.asc
Description: This is a digitally signed message part.
gesamt
So lots of files, many of which are (I suppose) relatively large, but do not
look "everything in one database" large to me.
(This is with Firefox 55.0.2.)
--
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - B
On Montag, 6. März 2017 00:53:40 CET Marc Joliet wrote:
> On Mittwoch, 1. März 2017 19:14:07 CET you wrote:
> > In any
> >
> > case, I started btrfs-check on the device itself.
>
> *Sigh*, I had to restart it, because I forgot to redirect to a file and
>
That's *way* more than I ran it the last time this error happened a few weeks
ago.
Greetings
--
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup
signature.asc
Description: This is a digitally signed message part.
> Personally speaking I don't think it is relative for your bug, but much
> like a normal extent tree corruption seen in mail list.
OK, so is there anything else I can do?
Greetings
--
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup
signature.asc
Description: This is a digitally signed message part.
On Friday 03 March 2017 09:09:57 Qu Wenruo wrote:
> At 03/02/2017 05:44 PM, Marc Joliet wrote:
> > On Wednesday 01 March 2017 19:14:07 Marc Joliet wrote:
> >> In any
> >> case, I started btrfs-check on the device itself.
> >
> > OK, it's still running, but
On Wednesday 01 March 2017 19:14:07 Marc Joliet wrote:
> In any
> case, I started btrfs-check on the device itself.
OK, it's still running, but the output so far is:
# btrfs check --mode=lowmem --progress /dev/sdb2
Checking filesystem on /dev/sdb2
UUID: f97b3cda-15e8-418b-bb9b-235391
On Thursday 02 March 2017 08:43:53 Qu Wenruo wrote:
> At 02/02/2017 08:01 PM, Marc Joliet wrote:
> > On Sunday 28 August 2016 15:29:08 Kai Krakow wrote:
> >> Hello list!
> >
> > Hi list
>
> [kernel message snipped]
>
> >> Btrfs --repair refus
On Wednesday 01 March 2017 19:14:07 Marc Joliet wrote:
> > > Also, the image is complete, so I only need to find somewhere where I
> > > can
> > > upload a 9.4 GB file.
> >
> >
> >
> > Is it a compressed dump? Dumped with btrfs-image -c9?
>
&
On Wednesday 01 March 2017 19:14:07 Marc Joliet wrote:
> > And btrfs check --mode=lowmem is also recommended as in some rare case,
> > low mem mode can detect bug which original mode doesn't.
>
> I did see differences in output the last time around (again, see my
&g
On Wednesday 01 March 2017 17:32:35 Qu Wenruo wrote:
> At 03/01/2017 04:23 PM, Marc Joliet wrote:
> > On Tuesday 28 February 2017 23:14:54 Marc Joliet wrote:
> >> I think I'm at that point now myself, unless anybody has any other ideas.
> >
> > For example, could
On Tuesday 28 February 2017 23:14:54 Marc Joliet wrote:
> I think I'm at that point now myself, unless anybody has any other ideas.
For example, could the --init-extent-tree option to btrfs-check help, given
that I needed to pass -w to btrfs-image?
Also, the image is complete, so I only n
oo, if you
haven't tried it already.
Greetings
--
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup
signature.asc
Description: This is a digitally signed message part.
On Saturday 11 February 2017 03:01:39 Kai Krakow wrote:
> Am Fri, 10 Feb 2017 23:15:03 +0100
>
> schrieb Marc Joliet <mar...@gmx.de>:
> > # btrfs filesystem df /media/MARCEC_BACKUP/
> > Data, single: total=851.00GiB, used=831.36GiB
> > System, DUP: total=64.00MiB,
Sorry for the late reply, see below for why :) .
On Friday 03 February 2017 23:44:10 Kai Krakow wrote:
> Am Thu, 02 Feb 2017 13:01:03 +0100
>
> schrieb Marc Joliet <mar...@gmx.de>:
[...]
> > > Btrfs --repair refused to repair the filesystem telling me something
> &
sdd2
The file system is mounted with "noatime,compress,comment=systemd.automount".
In my case the crash also happened during high I/O load (three btrfs-
send/receive backups running at the same time). If "usebackuproot" (now
called "recovery"?) fails, then I'll just wip
On Tuesday 06 December 2016 00:22:39 Marc Joliet wrote:
> On Monday 05 December 2016 11:16:35 Marc Joliet wrote:
> [...]
>
> > https://dl.dropboxusercontent.com/u/5328255/arthur_root_4.7.3_sanitized.im
> > ag e.xz
> > https://dl.dropboxusercontent.com/u/5328255/art
On Saturday 17 December 2016 00:18:13 Marc Joliet wrote:
> The initial results with btrfs-check's low-memory mode found
> reference count mismatches, but that seems to have been a false positive,
> since btrfs-check's normal mode does not find them.
FWIW, just in case this wasn't kno
On Saturday 17 December 2016 00:18:13 Marc Joliet wrote:
> Is this something that btrfs-check can safely repair, or that is perhaps
> even harmless?
Never mind, I just found that this has been repairable since btrfs-progs 3.19.
Greetings
--
Marc Joliet
--
"People who think they know
bytes: 11120295936
total fs tree bytes: 8620965888
total extent tree bytes: 1368756224
btree space waste bytes: 2415249740
file data blocks allocated: 19427350777856
referenced 1003936649216
Greetings
--
Marc Joliet
--
"People who think they know everything really annoy those of us who kn
/btrfs --version
btrfs-progs v4.8.5
I can't show any other output because btrfs-check is still running. I can
only say that the file system is 1TB large and about 88% full (fuller than
normal, which is about 85%).
Greetings
--
Marc Joliet
--
"People who think they know everything really annoy
g some
specific issue, I'm pretty sure you're wrong about that. Maybe you're
thinking of the occasionally mentioned old dedup kernel implementation?
--
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup
signature
On Tuesday 06 December 2016 11:12:12 Marc Joliet wrote:
> I have disabled quotas already (first thing I did after
> mounting). However, there were definitely 20-30, maybe more (enough for
> 2, maybe 3, console pages -- I don't know how many lines the initramfs
> rescue shell ha
On Tuesday 06 December 2016 08:29:48 Qu Wenruo wrote:
> At 12/05/2016 10:43 PM, Marc Joliet wrote:
> > On Monday 05 December 2016 12:01:28 Marc Joliet wrote:
> >>> This seems to be a NULL pointer bug in qgroup relocation fix.
> >>>
> >>>
> &
On Monday 05 December 2016 11:16:35 Marc Joliet wrote:
[...]
> https://dl.dropboxusercontent.com/u/5328255/arthur_root_4.7.3_sanitized.imag
> e.xz
> https://dl.dropboxusercontent.com/u/5328255/arthur_root_4.8.5_sanitized.ima
> ge.xz
BTW, since my problem appears to have been known,
On Monday 05 December 2016 12:01:28 Marc Joliet wrote:
> > This seems to be a NULL pointer bug in qgroup relocation fix.
> >
> >
> >
> > The latest fix (not merged yet) should address it.
> >
> >
> >
> > You could try the for-next-201611
On Monday 05 December 2016 12:01:28 Marc Joliet wrote:
> > You could try the for-next-20161125 branch from David to fix it:
> > https://github.com/kdave/btrfs-devel/tree/for-next-20161125
>
> OK, I'll try that, thanks! I just have to wait for it to finish cloning...
FWIW,
On Monday 05 December 2016 10:00:13 Marc Joliet wrote:
> OK, I'll post the URLs once the images are uploaded. (I had Dropbox public
> URLs right before my desktop crashed -- see below -- but now dropbox-cli
> doesn't want to create them.)
Alright, here you go:
https://dl.dropboxuserco
On Sunday 04 December 2016 11:52:40 Chris Murphy wrote:
> On Sun, Dec 4, 2016 at 9:02 AM, Marc Joliet <mar...@gmx.de> wrote:
> > Also, now the file system fails with the BUG I mentioned, see here:
> >
> > [Sun Dec 4 12:27:07 2016] BUG: unable to h
On Sunday 04 December 2016 18:24:08 Duncan wrote:
> Marc Joliet posted on Sun, 04 Dec 2016 17:02:48 +0100 as excerpted:
> > That's a good idea, although I'll probably start with sysrescuecd (Linux
> > 4.8.5 and btrfs-progs 4.7.3), as I already have experience with it.
> &g
On Sunday 04 December 2016 03:10:19 Adam Borowski wrote:
> On Sat, Dec 03, 2016 at 10:46:40PM +0100, Marc Joliet wrote:
> > As it's a rescue shell, I have only the one shell AFAIK, and it's occupied
> > by mount. So I can't tell if there are dmesg entries, however, when this
>
OK, so I tried a few things, to now avail, more below.
On Saturday 03 December 2016 15:56:45 Chris Murphy wrote:
> On Sat, Dec 3, 2016 at 2:46 PM, Marc Joliet <mar...@gmx.de> wrote:
> > On Saturday 03 December 2016 13:42:42 Chris Murphy wrote:
> >> On Sat, Dec 3, 2016
On Saturday 03 December 2016 13:42:42 Chris Murphy wrote:
> On Sat, Dec 3, 2016 at 11:40 AM, Marc Joliet <mar...@gmx.de> wrote:
> > Hello all,
> >
> > I'm having some trouble with btrfs on a laptop, possibly due to qgroups.
> > Specifically, some file system ac
le to avoid reformatting: how do I properly disable quota
support?
(BTW, searching for qgroup_fix_relocated_data_extents turned up the ML thread
"[PATCH] Btrfs: fix endless loop in balancing block groups", could that be
related?)
The laptop is currently running Gentoo with Linux 4.8.
k, say from compaction (if done in-
>place, not with a copy and rename), perhaps it's the reverse, the
>transition from written data blocks to inline metadata state.
I'm glad somebody is (publicly) thinking about this :-) !
Greetings
--
Marc Joliet
--
"People who think they
Am Saturday 07 May 2016
schrieb Marc Joliet <mar...@gmx.de>
>I'm thinking of filing
>a bug report with dovecot; perhaps none of their devs test with btrfs?
So I did this, and got a little bit of feedback. Quoting from the reply I
got:
"*.index.log files are always appended
On Sunday 06 December 2015 04:21:30 Duncan wrote:
>Marc Joliet posted on Sat, 05 Dec 2015 15:11:51 +0100 as excerpted:
>> I do think it's interesting that compression (even with LZO) seems to
>> have offset the extra space wastage caused by autodefrag.
>
>I've seen (I think) y
wasted space. I'll see how it
develops over the next two weeks, but I expect the ratio to become similar to
my desktop (probably less, since there is also a lot of music on there).
I would love to answer the question for my backup drive, but du took too long
(> 1 h) so I stopped it :-( . I
On Saturday 05 December 2015 14:37:05 Marc Joliet wrote:
>My desktop looks like this:
>
>% df -h
>DateisystemGröße Benutzt Verf. Verw% Eingehängt auf
>/dev/sda1 108G 79G 26G 76% /
>[...]
>
>For / I get a total of about 8G or at least 9% space saving:
./max.).
You can also see this very nicely with scrub runs (I use dstat for this):
they start out at the max., but gradually slow down as they progress.
HTH
--
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup
signature.asc
Description: This is a digitally signed message part.
On Wednesday 28 October 2015 05:21:13 Duncan wrote:
>Marc Joliet posted on Tue, 27 Oct 2015 21:54:40 +0100 as excerpted:
>>>IOW, does it take a full reboot to clear the problem, or is a simple
>>>ro/rw mount cycle enough, or an unmount/remount?
>>>
>> Seems
On Tuesday 27 October 2015 06:23:06 Duncan wrote:
>Marc Joliet posted on Mon, 26 Oct 2015 15:23:39 +0100 as excerpted:
>> Occasionally they go away by themselves, but usually I have to reboot to
>> make them go away. This happens when getmail attempts to fetch mail,
>
single: total=512.00MiB, used=0.00B
The filesystem is mounted as (leaving out subvolume mounts which use the same
mount options):
/dev/sda1 on / type btrfs (rw,noatime,compress=lzo,ssd,discard,space_cache)
Greetings,
--
Marc Joliet
--
"People who think they know everything really annoy thos
Am Fri, 14 Aug 2015 23:37:37 +0200
schrieb Marc Joliet mar...@gmx.de:
If I notice anything amiss, I'll report back.
I haven't noticed anything amiss, so I'm marking this thread as SOLVED.
--
Marc Joliet
--
People who think they know everything really annoy those of us who know we
don't
Am Sat, 15 Aug 2015 05:10:57 + (UTC)
schrieb Duncan 1i5t5.dun...@cox.net:
Marc Joliet posted on Fri, 14 Aug 2015 23:37:37 +0200 as excerpted:
(One other thing I found interesting was that btrfs scrub didn't care
about the link count errors.)
A lot of people are confused about
Am Fri, 14 Aug 2015 10:05:55 +0200
schrieb Marc Joliet mar...@gmx.de:
(I mean, that's part of being a user of btrfs at this stage)
I meant *being prepared* to file a bug report, not that one constantly has to
file bug reports :) .
--
Marc Joliet
--
People who think they know everything really
Am Thu, 13 Aug 2015 17:14:36 -0600
schrieb Chris Murphy li...@colorremedies.com:
On Thu, Aug 13, 2015 at 3:23 AM, Marc Joliet mar...@gmx.de wrote:
Speaking as a user, since fstrim -av still always outputs 0 bytes trimmed
on my system: what's the status of this? Did anybody ever file a bug
Am Thu, 13 Aug 2015 10:54:58 +0200
schrieb Marc Joliet mar...@gmx.de:
Am Thu, 13 Aug 2015 08:29:19 + (UTC)
schrieb Duncan 1i5t5.dun...@cox.net:
Marc Joliet posted on Thu, 13 Aug 2015 09:05:41 +0200 as excerpted:
Here's the actual output now, obtained via btrfs-progs 4.0.1 from
Am Thu, 13 Aug 2015 00:34:19 +0200
schrieb Marc Joliet mar...@gmx.de:
[...]
Since this is the root file system, I haven't gotten a copy of the actual
output
of btrfs check, though I have run it from an initramfs rescue shell. The
output I saw there was much like the following (taken from
Am Thu, 13 Aug 2015 08:29:19 + (UTC)
schrieb Duncan 1i5t5.dun...@cox.net:
Marc Joliet posted on Thu, 13 Aug 2015 09:05:41 +0200 as excerpted:
Here's the actual output now, obtained via btrfs-progs 4.0.1 from an
initramfs emergency shell:
checking extents checking free space cache
: total=65.00GiB, used=54.83GiB
System, single: total=32.00MiB, used=16.00KiB
Metadata, single: total=4.00GiB, used=1.76GiB
GlobalReserve, single: total=512.00MiB, used=0.00B
Greetings
--
Marc Joliet
--
People who think they know everything really annoy those of us who know we
don't - Bjarne Stroustrup
Metadata, single: total=4.00GiB, used=1.77GiB
GlobalReserve, single: total=512.00MiB, used=0.00B
Greetings
--
Marc Joliet
--
People who think they know everything really annoy those of us who know we
don't - Bjarne Stroustrup
pgpmXZfT7icaz.pgp
Description: Digitale Signatur von OpenPGP
Am Mon, 13 Jul 2015 06:56:17 + (UTC)
schrieb Duncan 1i5t5.dun...@cox.net:
Marc Joliet posted on Sun, 12 Jul 2015 14:26:04 +0200 as excerpted:
I hope it's not out of place, but I have a few suggestions for the Wiki:
Just in case it wasn't obvious... The wiki is open to user editing
Am Mon, 13 Jul 2015 19:21:54 +0200
schrieb Marc Joliet mar...@gmx.de:
OK, I'll make the changes then (sans kernel log).
Just a heads up: I accepted the terms of service, but the link goes to a
non-existent wiki page.
--
Marc Joliet
--
People who think they know everything really annoy those
Am Mon, 13 Jul 2015 18:30:09 +0200
schrieb David Sterba dste...@suse.com:
On Mon, Jul 13, 2015 at 01:18:27PM +0200, Marc Joliet wrote:
Am Mon, 13 Jul 2015 06:56:17 + (UTC)
schrieb Duncan 1i5t5.dun...@cox.net:
Marc Joliet posted on Sun, 12 Jul 2015 14:26:04 +0200 as excerpted
-progs 4.1.1
news entry.
- The Linux v4.1 news entry is still TBD ;-) .
Greetings
--
Marc Joliet
--
People who think they know everything really annoy those of us who know we
don't - Bjarne Stroustrup
pgpFwZKnbRCn9.pgp
Description: Digitale Signatur von OpenPGP
), but IIRC nothing really serious.
--
Marc Joliet
--
People who think they know everything really annoy those of us who know we
don't - Bjarne Stroustrup
pgpazrScetd8J.pgp
Description: Digitale Signatur von OpenPGP
Am Fri, 23 Jan 2015 08:46:23 + (UTC)
schrieb Duncan 1i5t5.dun...@cox.net:
Marc Joliet posted on Fri, 23 Jan 2015 08:54:41 +0100 as excerpted:
Am Fri, 23 Jan 2015 04:34:19 + (UTC)
schrieb Duncan 1i5t5.dun...@cox.net:
Gareth Pye posted on Fri, 23 Jan 2015 08:58:08 +1100
moves the files to
another (temporary) subvolume? (And with future coreutils, by copying the files
without using reflinks and then removing the originals.)
[...]
--
Marc Joliet
--
People who think they know everything really annoy those of us who know we
don't - Bjarne Stroustrup
the last time I ran a scrub, so I was
hoping it was gone by now.
(On the upside, though, this isn't exactly the worst bug btrfs has ever
had ;) .)
Greetings
--
Marc Joliet
--
People who think they know everything really annoy those of us who know we
don't - Bjarne Stroustrup
pgpxeBuwdNml4.pgp
Am Wed, 10 Dec 2014 10:51:15 +0800
schrieb Anand Jain anand.j...@oracle.com:
Is there any relevant log in the dmegs ?
Not in my case; at least, nothing that made it into the syslog.
--
Marc Joliet
--
People who think they know everything really annoy those of us who know we
don't - Bjarne
by the commit
message, it looks like it. If so, can you say whether it will make it into
3.17.x?
Maybe I'm being overly paranoid, but I stuck with 3.16.7 because of this. (I
mean, I have backups, but there's no need to provoke a situation where I will
need them ;-) .)
--
Marc Joliet
--
People who think
-gentoo #1 SMP PREEMPT Fri Oct 31 22:45:54 CET 2014 x86_64
AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ AuthenticAMD GNU/Linux
# btrfs --version
Btrfs v3.17.1
Should I open a report on bugzilla?
--
Marc Joliet
--
People who think they know everything really annoy those of us who know we
don't
I bit the bullet and went through with it, and am keeping the original
backups until enough snapshots have accumulated in the new backup location
(both of my backups are on the same file system in different subvolumes).
greetings
jakob
HTH
--
Marc Joliet
--
People who think they know
Am Sat, 25 Oct 2014 14:35:33 -0600
schrieb Chris Murphy li...@colorremedies.com:
On Oct 25, 2014, at 2:33 PM, Chris Murphy li...@colorremedies.com wrote:
On Oct 25, 2014, at 6:24 AM, Marc Joliet mar...@gmx.de wrote:
First of all: does grub2 support booting from a btrfs file system
Am Sat, 25 Oct 2014 21:58:08 +0200
schrieb Marc Joliet mar...@gmx.de:
Am Sat, 25 Oct 2014 14:24:58 +0200
schrieb Marc Joliet mar...@gmx.de:
I can still access files on MARCEC_BACKUP just fine, and the snapshots are
still there (btrfs subvolume list succeeds).
Just an update
84 00 00 00 00 00 41
[ 5844.151353] RIP [8123b3ec] do_walk_down+0x54c/0x560
[ 5844.151353] RSP 8800156d3778
[ 5844.172535] ---[ end trace bf07dd9e2f7fb343 ]---
--
Marc Joliet
--
People who think they know everything really annoy those of us who know we
don't - Bjarne
Am Sat, 25 Oct 2014 14:24:58 +0200
schrieb Marc Joliet mar...@gmx.de:
I can still access files on MARCEC_BACKUP just fine, and the snapshots are
still there (btrfs subvolume list succeeds).
Just an update: that was true for a while, but at one point listing directories
and accessing the file
Am Tue, 22 Jul 2014 03:26:39 + (UTC)
schrieb Duncan 1i5t5.dun...@cox.net:
Marc Joliet posted on Tue, 22 Jul 2014 01:30:22 +0200 as excerpted:
And now that the background deletion of the old snapshots is done, the file
system ended up at:
# btrfs filesystem df /run/media/marcec
Am Sun, 20 Jul 2014 21:44:40 +0200
schrieb Marc Joliet mar...@gmx.de:
[...]
What I did:
- delete the single largest file on the file system, a 12 GB VM image, along
with all subvolumes that contained it
- rsync it over again
[...]
I want to point out at this point, though, that doing
Am Mon, 21 Jul 2014 15:22:16 +0200
schrieb Marc Joliet mar...@gmx.de:
Am Sun, 20 Jul 2014 21:44:40 +0200
schrieb Marc Joliet mar...@gmx.de:
[...]
What I did:
- delete the single largest file on the file system, a 12 GB VM image, along
with all subvolumes that contained
Am Tue, 22 Jul 2014 00:30:57 +0200
schrieb Marc Joliet mar...@gmx.de:
Am Mon, 21 Jul 2014 15:22:16 +0200
schrieb Marc Joliet mar...@gmx.de:
Am Sun, 20 Jul 2014 21:44:40 +0200
schrieb Marc Joliet mar...@gmx.de:
[...]
What I did:
- delete the single largest file on the file
), -nan% left
(Also, this is with Gentoo kernel 3.15.6 now.)
--
Marc Joliet
--
People who think they know everything really annoy those of us who know we
don't - Bjarne Stroustrup
dmesg4.log.xz
Description: application/xz
signature.asc
Description: PGP signature
Am Sat, 19 Jul 2014 18:53:03 -0600
schrieb Chris Murphy li...@colorremedies.com:
On Jul 19, 2014, at 2:58 PM, Marc Joliet mar...@gmx.de wrote:
Am Sat, 19 Jul 2014 22:10:51 +0200
schrieb Marc Joliet mar...@gmx.de:
[...]
Another random idea: the number of errors decreased
is there but
recovery code is still incomplete.
[0] https://btrfs.wiki.kernel.org/index.php/Conversion_from_Ext3
Thanks
--
Marc Joliet
--
People who think they know everything really annoy those of us who know we
don't - Bjarne Stroustrup
signature.asc
Description: PGP signature
Am Sun, 20 Jul 2014 12:22:33 +0200
schrieb Marc Joliet mar...@gmx.de:
[...]
I'll try this and see, but I think I have more files 1GB than would account
for this error (which comes towards the end of the balance when only a few
chunks are left). I'll see what find /mnt -type f -size +1G finds
Start weitergeleitete Nachricht:
Huh, turns out the Reply-To was to Chris Murphy, so here it is again for the
whole list.
Datum: Sat, 19 Jul 2014 20:34:34 +0200
Von: Marc Joliet mar...@gmx.de
An: Chris Murphy li...@colorremedies.com
Betreff: Re: ENOSPC errors during balance
Am Sat, 19 Jul
Am Sat, 19 Jul 2014 22:10:51 +0200
schrieb Marc Joliet mar...@gmx.de:
[...]
Another random idea: the number of errors decreased the second time I ran
balance (from 4 to 2), I could run another full balance and see if it keeps
decreasing.
Well, this time there were still 2 ENOSPC errors
80 matches
Mail list logo
