search for: scrubbers

On Tue, 31 Jan 2023 at 09:09, Chris Clayton <chris2553 at googlemail.com> wrote: > > Hi again. > > On 30/01/2023 20:19, Chris Clayton wrote: > > Thanks, Ben. > > <snip> > > >> Hey, > >> > >> This is a complete shot-in-the-dark, as I don't see this behaviour on > >> *any* of my boards. Could you try the attached patch

On Sun, 19 Feb 2023 at 04:55, Chris Clayton <chris2553 at googlemail.com> wrote: > > > > On 18/02/2023 15:19, Chris Clayton wrote: > > > > > > On 18/02/2023 12:25, Karol Herbst wrote: > >> On Sat, Feb 18, 2023 at 1:22 PM Chris Clayton <chris2553 at googlemail.com> wrote: > >>> > >>> > >>> > >>> On

On Mon, Feb 20, 2023 at 11:51 AM Chris Clayton <chris2553 at googlemail.com> wrote: > > > > On 20/02/2023 05:35, Ben Skeggs wrote: > > On Sun, 19 Feb 2023 at 04:55, Chris Clayton <chris2553 at googlemail.com> wrote: > >> > >> > >> > >> On 18/02/2023 15:19, Chris Clayton wrote: > >>> > >>> > >>> On

Hi Sweta, Thanks, this drive me some more questions: 1. What is the reason of delaying signature creation ? 2. As a same file (replicated or dispersed) having different signature thought bricks is by definition an error, it would be good to triggered it during a scrub, or with a different tool. Is something like this planned ? Cheers ? C?dric Lemarchand > On 18 Apr 2018, at 07:53, Sweta

On Fri, Mar 10, 2023 at 10:26?AM Chris Clayton <chris2553 at googlemail.com> wrote: > > Hi. > > Is it likely that this fix will be sumbmitted to mainline during the ongoing 6.3 development cycle? > yes, it's already pushed to drm-misc-fixed, which then will go into the current devel cycle. I just don't know when it's the next time it will be pushed upwards, but it

On Sat, Feb 18, 2023 at 1:22 PM Chris Clayton <chris2553 at googlemail.com> wrote: > > > > On 15/02/2023 11:09, Karol Herbst wrote: > > On Wed, Feb 15, 2023 at 11:36 AM Linux regression tracking #update > > (Thorsten Leemhuis) <regressions at leemhuis.info> wrote: > >> > >> On 13.02.23 10:14, Chris Clayton wrote: > >>> On 13/02/2023

Hi, A client has a glusterfs cluster that's behaving weirdly after some issues during upgrade. They upgraded a glusterfs 2+1 cluster (replica with arbiter) from 3.10.9 to 3.12.4 on Centos and now have weird issues and some files maybe being corrupted. They also switched from nfs ganesha that crashed every couple of days to glusterfs subdirectory mounting. Subdirectory mounting was the

Hi! Make scrub_heap_pages() print from where to where it scrubs pages. Signed-off-by: Christoph Egger <Christoph.Egger@amd.com> This patch uncovers a strange behaviour on 32bit. On 64bit I get this: (XEN) Scrubbing Free RAM 0xffff830000100000 -> 0xffff83003fff0000: ....done. On 32bit I get this: (XEN) Scrubbing Free RAM 0xffc00000 -> 0xdefb0000:

...lace the venerable html-scanner with Loofah, picking up where this issue left off: https://github.com/rails/rails/issues/2550. Rafael França was assigned to that issue and he is my mentor during the summer. I want to hear your thoughts about a new API that will take advantage of Loofahs custom scrubbers. Here''s the example I gave in my project proposal<https://github.com/kaspth/gsoc-application> : class Comment < ActiveRecord::Base # block based # block takes a node scrubs :body do |node| node.remove if node.name == "script" end # method based # method...

Hi Guys, My first post here. I have recently installed RH9 and am having some rather wierd problems that make me suspect file corruption. After some useage the machine locked up hard when trying to use 3d graphics (I have a radeon 7200 with dri enabled). After this happened occasionally the system refuses to boot- it stops at the apm line of the kernel boot process. I tried looking at my hard

Hello Alexandre Courbot, The patch 5429f82f3415: "drm/nouveau/secboot: add gp102/gp104/gp106/gp107 support" from Jan 26, 2017, leads to the following static checker warning: drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gp102.c:63 gp102_run_secure_scrub() warn: passing zero to 'PTR_ERR' drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gp102.c 46 static int 47

Is there a method to view the status of the rams ecc single or double bit errors? I would like to confirm that ecc on my xeon e5520 and ecc ram are performing their role since memtest is ambiguous. I am running memory test on a p6t6 ws, e5520 xeon, 2gb samsung ecc modules and this is what is on the screen: Chipset: Core IMC (ECC : Detect / Correct) However, further down "ECC" is

I am having some trouble calculating the duration of my speex files. I am writing a speex player in Java and I am using the JSpeex port of the codec which works but doesn't give me the audio duration which I need to show progress or implement a scrubber. JSpeex appears to be all but dead but I don't see any other option for Java playback. I have tried the method posted here:

Say I''m firing off an at(1) or cron(1) job to do scrubs, and say I want to scrub two pools sequentially because they share one device. The first pool, BTW, is a mirror comprising of a smaller disk and a subset of a larger disk. The other pool is the remainder of the larger disk. I see no documentation mentioning how to scrub, then wait-until-completed. I''m happy to be pointed

On Thu, Apr 30, 2020 at 12:15:28AM -0400, Ilia Mirkin wrote: > Hi Alexey, > > On Fri, Apr 24, 2020 at 10:52 PM Alexey Dobriyan <adobriyan at gmail.com> wrote: > > > > gp104 refuses to switch to "graphic" mode and show anything past > > this line: > > > > fb0: switching to nouveaufb from EFI VGA > > > > Machine is fine, as

In the same way that the core LLVM libraries have support routines for DWARF, I think that both mangling and demangling should be provided as well. I suspect that the 'Support' library is the best we have, although eventually we need to split this library up a bit. That's not really your problem though. The bigger problem is that we don't have any good way of sharing code between

For some reason, I didn't get Brians email, but I noticed it was replied to, so I'll copy from the archive > Is there an overview - in plain English - summarizing the API changes? No, not yet, as it isn't final yet. However, for the API changes, one only has to look at the header files, not the actual source files. > Without diving in to the source changes, my first question

Hi Cedric, Any file is picked up for signing by the bitd process after the predetermined wait of 120 seconds. This default value is captured in the volume option 'features.expiry-time' and is configurable - in your case, it can be set to 0 or 1. Point 2 is correct. A file corrupted before the bitrot signature is generated will not be successfully detected by the scrubber. That would

[adding various lists and the two other nouveau maintainers to the list of recipients] For the rest of this mail: [TLDR: I'm adding this report to the list of tracked Linux kernel regressions; the text you find below is based on a few templates paragraphs you might have encountered already in similar form. See link in footer if these mails annoy you.] On 18.01.23 21:59, Chris Clayton wrote:

On 04/17/2018 06:25 PM, Omar Kohl wrote: > Hi, > > I have a question regarding bitrot detection. > > Following the RedHat manual (https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3.3/html/administration_guide/bitrot-restore_corrupt_file) I am trying out bad-file-restoration after bitrot. > > "gluster volume bitrot VOLNAME status" gets me the