rately from regular scripts, but I forgot the specifics.)
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.
Am Dienstag, 15. Januar 2019, 09:33:40 CET schrieb Duncan:
> Marc Joliet posted on Mon, 14 Jan 2019 12:35:05 +0100 as excerpted:
> > Am Montag, 14. Januar 2019, 06:49:58 CET schrieb Duncan:
> > [...]
> >
> >> Unless you have a known reason not to[1], running noatime
ecided to remove noatime from my systems' mount options is
because I use systemd-tmpfiles to clean up cache directories, for which it is
necessary to leave atime intact (since caches are often Write Once Read Many).
--
Marc Joliet
--
"People who think they know everything really annoy t
g files 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
idea what possibly 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.
5DBFFFDD
427Minsgesamt
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&#x
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
> quite
check output!
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.
s what the btrfs wiki recommends.
> 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
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-2
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
>
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, cou
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
ur case, too, 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 :
> > # btrfs filesystem df /media/MARCEC_BACKUP/
> > Data, single: total=851.00GiB, used=831.36GiB
> > System, DUP: total=64.00MiB, used=120.00K
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 :
[...]
> > > Btrfs --repair refused to repair the filesystem telling me something
> > > about compressed
devid1 size 976.56GiB used 877.31GiB path /dev/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 "usebac
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
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
tree 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 w
U/Linux
% /sbin/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 ever
referencing 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 Str
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
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...
F
On Monday 05 December 2016 08:39:02 Qu Wenruo wrote:
> At 12/04/2016 02:40 AM, Marc Joliet wrote:
> > Hello all,
> >
> > I'm having some trouble with btrfs on a laptop, possibly due to qgroups.
> > Specifically, some file system activities (e.g., snapshot creatio
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.dro
On Sunday 04 December 2016 11:52:40 Chris Murphy wrote:
> On Sun, Dec 4, 2016 at 9:02 AM, Marc Joliet wrote:
> > Also, now the file system fails with the BUG I mentioned, see here:
> >
> > [Sun Dec 4 12:27:07 2016] BUG: unable to handle kernel paging request at
> > ff
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.
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,
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 wrote:
> > On Saturday 03 December 2016 13:42:42 Chris Murphy wrote:
> >> On Sat, Dec 3, 2016 at 11:40 AM,
On Saturday 03 December 2016 13:42:42 Chris Murphy wrote:
> On Sat, Dec 3, 2016 at 11:40 AM, Marc Joliet wrote:
> > Hello all,
> >
> > I'm having some trouble with btrfs on a laptop, possibly due to qgroups.
> > Specifically, some file system act
ther tool? Or...?
Also, should I be able 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
f all the files had just shrunk, 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
-
Am Saturday 07 May 2016
schrieb Marc Joliet
>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 to using O_AP
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 (
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:
t of 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
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
OK, upgrading to gentoo-sources 4.1.11 didn't help, so I tried these steps.
More inline below.
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 hav
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,
>> w
single: total=7.00GiB, used=2.10GiB
GlobalReserve, 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
--
"Peopl
Am Fri, 14 Aug 2015 23:37:37 +0200
schrieb Marc Joliet :
> 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
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 err
Am Thu, 13 Aug 2015 10:54:58 +0200
schrieb Marc Joliet :
> 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 no
Am Fri, 14 Aug 2015 10:05:55 +0200
schrieb Marc Joliet :
> (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
Am Thu, 13 Aug 2015 17:14:36 -0600
schrieb Chris Murphy :
> On Thu, Aug 13, 2015 at 3:23 AM, Marc Joliet 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
cef
Total devices 2 FS bytes used 597.75GiB
devid1 size 931.51GiB used 600.03GiB path /dev/sdc
devid2 size 931.51GiB used 600.03GiB path /dev/sdb
Label: 'MARCEC_BACKUP' uuid: f97b3cda-15e8-418b-bb9b-235391ef2a38
Total devices 1 FS bytes used 807.59GiB
devid1 size 976.56GiB used 837.06GiB path /dev/sdd2
btrfs-progs v4.1.2
# btrfs filesystem df /
Data, single: 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
pgpe5zrE9jGKM.pgp
Description: Digitale Signatur von OpenPGP
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:
> >
Am Thu, 13 Aug 2015 00:34:19 +0200
schrieb Marc Joliet :
[...]
> 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 fol
ilesystem df /
Data, single: total=70.00GiB, used=57.53GiB
System, single: total=32.00MiB, used=16.00KiB
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 19:21:54 +0200
schrieb Marc Joliet :
> 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 th
Am Mon, 13 Jul 2015 18:30:09 +0200
schrieb David Sterba :
> 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
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 ob
it: "hilights" should be "highlights" in the btrfs-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
ut 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>:
> >
> >> G
t should be pretty fast since the one side is all memory.
With current coreutils, wouldn't that also work if he 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
--
"
1,
respectively, and didn't see this issue 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 thos
Am Wed, 10 Dec 2014 10:51:15 +0800
schrieb Anand Jain :
> 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" -
ry and make the
> "expected blah, have 0" type errors happen.
Just a quick question from a user: does Filipe's patch "Btrfs: fix race between
fs trimming and block group remove/allocation" fix this? Judging 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 they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup
signature.asc
Description: PGP signature
# uname -a
Linux marcec 3.16.7-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
s.
This is why you need to make an initial send: to give both volumes a common
frame of reference, so to speak.
So 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 t
Am Sat, 25 Oct 2014 21:58:08 +0200
schrieb Marc Joliet :
> Am Sat, 25 Oct 2014 14:24:58 +0200
> schrieb Marc Joliet :
>
> > I can still access files on MARCEC_BACKUP just fine, and the snapshots are
> > still there ("btrfs subvolume list" succeeds).
>
> Just
Am Sat, 25 Oct 2014 14:35:33 -0600
schrieb Chris Murphy :
>
> On Oct 25, 2014, at 2:33 PM, Chris Murphy wrote:
>
> >
> > On Oct 25, 2014, at 6:24 AM, Marc Joliet wrote:
> >>
> >> First of all: does grub2 support booting from a btrfs file system with
&g
Am Sat, 25 Oct 2014 14:24:58 +0200
schrieb Marc Joliet :
> 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 th
fe ff <0f> 0b
0f 0b 0f 0b 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 41
[ 5844.151353] RIP [] do_walk_down+0x54c/0x560
[ 5844.151353] RSP
[ 5844.172535] ---[ end trace bf07dd9e2f7fb343 ]---
--
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 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:
> >
Am Tue, 22 Jul 2014 00:30:57 +0200
schrieb Marc Joliet :
> Am Mon, 21 Jul 2014 15:22:16 +0200
> schrieb Marc Joliet :
>
> > Am Sun, 20 Jul 2014 21:44:40 +0200
> > schrieb Marc Joliet :
> >
> > [...]
> > > What I did:
> > >
> > > - d
Am Mon, 21 Jul 2014 15:22:16 +0200
schrieb Marc Joliet :
> Am Sun, 20 Jul 2014 21:44:40 +0200
> schrieb Marc Joliet :
>
> [...]
> > What I did:
> >
> > - delete the single largest file on the file system, a 12 GB VM image, along
> > with all subvolumes t
Am Sun, 20 Jul 2014 21:44:40 +0200
schrieb Marc Joliet :
[...]
> 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
Oh, and because I'm forgetful, here the new dmesg output. The new content
(relative to dmesg4) starts at line 2513.
--
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup
dmesg5.log.xz
Descrip
Am Sun, 20 Jul 2014 13:40:54 +0200
schrieb Marc Joliet :
> Am Sun, 20 Jul 2014 12:22:33 +0200
> schrieb Marc Joliet :
>
> [...]
> > I'll try this and see, but I think I have more files >1GB than would account
> > for this error (which comes towards the en
Am Sun, 20 Jul 2014 12:22:33 +0200
schrieb Marc Joliet :
[...]
> 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 /m
, and try the alternative move-off-
> filesystem-temporarily method.
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
Am Sat, 19 Jul 2014 18:53:03 -0600
schrieb Chris Murphy :
>
> On Jul 19, 2014, at 2:58 PM, Marc Joliet wrote:
>
> > Am Sat, 19 Jul 2014 22:10:51 +0200
> > schrieb Marc Joliet :
> >
> > [...]
> >> Another random idea: the number of errors decreased
'/mnt' is running
0 out of about 0 chunks balanced (0 considered), -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 22:10:51 +0200
schrieb Marc Joliet :
[...]
> 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.
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
An: Chris Murphy
Betreff: Re: ENOSPC errors during balance
Am Sat, 19 Jul 2014 11:38:08 -0600
schrieb Chris
87 matches
Mail list logo
