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
On Sat, Nov 7, 2015 at 11:22 PM, Christoph Anton Mitterer
wrote:
> Hey.
>
> I just repeatedly did the following twice on a ~8GB USB stick, under
> Debian sid (ergo kernel 4.2.0-1-amd64, btrfsprogs 4.2.2-1).
>
> First, created some GPT on the stick:
> Number Start (sector)
[...]
>3 3145728 4194303 512.0 MiB 8300 Linux filesystem
[...]
> root@heisenberg:~# mkfs.btrfs --nodiscard --label boot-data /dev/sdb3
> btrfs-progs v4.2.2
> See http://btrfs.wiki.kernel.org for more information.
>
> Label: boot-data
> UUID:
Henk Slager posted on Sun, 08 Nov 2015 19:18:19 +0100 as excerpted:
> [...]
>>3 3145728 4194303 512.0 MiB 8300 Linux filesystem
> [...]
>> root@heisenberg:~# mkfs.btrfs --nodiscard --label boot-data /dev/sdb3
>> btrfs-progs v4.2.2 See http://btrfs.wiki.kernel.org for more
>>
On Sun, 2015-11-08 at 20:39 +, Duncan wrote:
> Wow, yes! Good catch, Henk! =:^) Hugo obviously didn't catch it,
> and I
> wouldn't have either, as the bad size detection behavior is so
> unexpected, it just wouldn't occur to me to look!
Hmm... all that *may* be more likely an error of
Christoph Anton Mitterer posted on Sun, 08 Nov 2015 23:10:57 +0100 as
excerpted:
> On Sun, 2015-11-08 at 20:39 +, Duncan wrote:
>> Wow, yes! Good catch, Henk! =:^) Hugo obviously didn't catch it,
>> and I wouldn't have either, as the bad size detection behavior is so
>> unexpected, it just
On Sat, 2015-11-07 at 23:30 +, Hugo Mills wrote:
> These are all really small.
Well enough for booting =)
> I would suggest running mkfs with --mixed for all of these
> filesystems and trying again.
I thought btrfs would do that automatically:
On Sun, Nov 08, 2015 at 12:22:42AM +0100, Christoph Anton Mitterer wrote:
> Hey.
>
> I just repeatedly did the following twice on a ~8GB USB stick, under
> Debian sid (ergo kernel 4.2.0-1-amd64, btrfsprogs 4.2.2-1).
>
> First, created some GPT on the stick:
> Number Start (sector)End
22 matches
Mail list logo