Re: Regression in Linux 5.5.0-rc[1-5]: btrfs send/receive out of memory

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jan 28, 2020 at 3:08 PM Filipe Manana <fdmanana@xxxxxxxxx> wrote:
>
> On Tue, Jan 28, 2020 at 3:05 PM Craig Andrews <candrews@xxxxxxxxxxxxxxxx> wrote:
> >
> > On 2020-01-28 10:02, Filipe Manana wrote:
> > > On Tue, Jan 28, 2020 at 2:46 PM Craig Andrews
> > > <candrews@xxxxxxxxxxxxxxxx> wrote:
> > >>
> > >> On 2020-01-27 08:44, Filipe Manana wrote:
> > >> > On Sat, Jan 25, 2020 at 11:18 AM Stéphane Lesimple
> > >> > <stephane_btrfs2@xxxxxxxxxxx> wrote:
> > >> >>
> > >> >> > ERROR: failed to clone extents to var/amavis/db/__db.001: Invalid argument
> > >> >>
> > >> >> If I may add another data point here, I'm also encountering this issue
> > >> >> on a 5.5.0-rc6, with the btrfs-rc7 patches applied to it (so as far as
> > >> >> btrfs is concerned, this is an rc7).
> > >> >>
> > >> >> On the first time, it happened after sending ~90 Gb worth of data, and
> > >> >> aborted (as I didn't specify the -E option to btrfs send). Then, I
> > >> >> retried with btrfs send -E 0, and it encountered the exact same error
> > >> >> on the same file.
> > >> >>
> > >> >> # btrfs send -v /tank/backups/.snaps/incoming/sendme/ | pv
> > >> >> 2>/dev/pts/23 | btrfs rec -E 0 /newfs/
> > >> >> At subvol /tank/backups/.snaps/incoming/sendme/
> > >> >> At subvol sendme
> > >> >> ERROR: failed to clone extents to
> > >> >> retroarch/x86_64/cores/mednafen_saturn_libretro.dll: Invalid argument
> > >> >> ERROR: failed to clone extents to
> > >> >> retroarch/x86_64/cores/mednafen_saturn_libretro.dll: Invalid argument
> > >> >
> > >> > This is probably the same case for which I sent a fix last week:
> > >> >
> > >> > https://patchwork.kernel.org/patch/11350129/
> > >> >
> > >> > Thanks.
> > >>
> > >> I applied that patch to 5.5.0-rc7 and that solved the problem. I can
> > >> now
> > >> do backups (which is a send/receive) successfully.
> > >>
> > >> >
> > >> >>
> > >> >> The send/receive is still going on for now, currently around the ~200
> > >> >> Gb mark.
> > >> >>
> > >> >> Bees is running on this FS (but I stopped it before doing the
> > >> >> send/receive).
> > >> >>
> > >> >> I can test patches if needed.
> > >> >>
> > >> >> --
> > >> >> Stéphane.
> > >>
> > >> The patch appears to have fixed my problems - thank you!
> > >
> > > Great!
> > >
> > > Can you reply to the patch's thread with a:
> > >
> > > Tested-by: Your Name <email@xxxxxxx>
> > >
> > > ?
> > >
> > > Or I can reply to it myself with that if you agree.
> > >
> > > Thanks!
> > >
> > >> ~Craig
> >
> >
> > Can you please send the reply?
> > Tested-by: Craig Andrews <candrews@xxxxxxxxxxxxxxxx>
>
> No problem, done. Thanks.

Actually I just realized one chunk of the patch can cause problems
with fallocated extents beyond a file's size and a hole that ends
right at the file's size (unlikely to be a common scenario anyway).
I also don't think it's needed. For my tests at least, removing it
doesn't cause any new problems and solves the problem with the invalid
clone operations.

Can you try it for your use case too?

To be clear, this is the new version of the patch:

https://pastebin.com/raw/vewZiG9J

(A shorter version of the original)

Thanks!



>
> >
> > And again, thank you!
> > ~Craig
>
>
>
> --
> Filipe David Manana,
>
> “Whether you think you can, or you think you can't — you're right.”



-- 
Filipe David Manana,

“Whether you think you can, or you think you can't — you're right.”




[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux