From: Joe L. <jo...@ge...> - 2018-05-22 19:29:08
|
On May 22, 2018, at 1:59 PM, Marco Milano <mar...@gm...> wrote: > > > On 05/22/2018 02:36 PM, Gandalf Corvotempesta wrote: >> Il giorno mar 22 mag 2018 alle ore 19:28 Marin Bernard <li...@ol...> >> ha scritto: >> Anyway, even if you scrub the whole ZFS pool, you won't get any advantage, >> ZFS is unable >> to recover by itself (without raid) and MooseFS is still unaware of >> corruption. > > MooseFS will be *aware* of the corruption during the read and will self heal > as I explained above. (Or during the checksum checking (native scrub) loop, > whichever comes first.) > >> Ok, chunk1 is corrupted, ZFS detected it during a scrub. And now ? >> ZFS doesn't have any replica to rebuild from. >> MooseFS is unaware of this because their native scrub takes months and >> no one is reading that file from a client (forcing the checksum >> verification). > > You seem to be making these constant claims about "native scrub taking months", > but I believe it was explained in earlier emails that this will depend on your > hardware configuration. I believe there was another email which basically said > this "native scrub speed" was much improved in version 4. > So I think it is fair to say that you should stop repeating this "native scrub takes months" claim, > or if you are not going to stop repeating it, at least put some qualifiers around it. > Or download v4, and see if the speed improved… It sounds like MooseFS does data consistency checking similarly to ZFS. They both seem to do periodic scrubs, and they both check the block they read/write. It seems like the complaint is that ZFS can’t tell MooseFS that it found a bad block. -Joe |