Re: 4.11 relocate crash, null pointer + rolling back a filesystem by X hours?

Marc MERLIN posted on Tue, 23 May 2017 09:58:47 -0700 as excerpted: > That's a valid point, and in my case, I can back it up/restore, it just > takes a bit of time, but most of the time is manually babysitting all > those subvolumes that I need to recreate by hand with btrfs send/restore >

Re: 4.11 relocate crash, null pointer + rolling back a filesystem by X hours?

On Tue, May 02, 2017 at 05:01:02AM +, Duncan wrote: > Marc MERLIN posted on Mon, 01 May 2017 20:23:46 -0700 as excerpted: > > > Also, how is --mode=lowmem being useful? > > FWIW, I just watched your talk that's linked from the wiki, and wondered > what you were doing these days as I hadn't

Re: 4.11 relocate crash, null pointer + rolling back a filesystem by X hours?

Am Fri, 5 May 2017 08:43:23 -0700 schrieb Marc MERLIN : [missing quote of the command] > > Corrupted blocks are corrupted, that command is just trying to > > corrupt it again. > > It won't do the black magic to adjust tree blocks to avoid them. > > I see. you may hve seen

Re: 4.11 relocate crash, null pointer + rolling back a filesystem by X hours?

Thanks again for your answer. Obviously even if my filesystem is toast, it's useful to learn from what happened. On Fri, May 05, 2017 at 01:03:02PM +0800, Qu Wenruo wrote: > > > So unfortunately, your fs/subvolume trees are also corrupted. > > > And almost no chance to do a graceful recovery. > >

Re: 4.11 relocate crash, null pointer + rolling back a filesystem by X hours?

At 05/05/2017 10:40 AM, Marc MERLIN wrote: On Fri, May 05, 2017 at 09:19:29AM +0800, Qu Wenruo wrote: Sorry for not noticing the link. no problem, it was only one line amongst many :) Thanks much for having had a look. [Conclusion] After checking the full result, some of fs/subvolume

Re: 4.11 relocate crash, null pointer + rolling back a filesystem by X hours?

On Fri, May 05, 2017 at 09:19:29AM +0800, Qu Wenruo wrote: > Sorry for not noticing the link. no problem, it was only one line amongst many :) Thanks much for having had a look. > [Conclusion] > After checking the full result, some of fs/subvolume trees are corrupted. > > [Details] > Some

Re: 4.11 relocate crash, null pointer + rolling back a filesystem by X hours?

At 05/05/2017 09:19 AM, Qu Wenruo wrote: At 05/02/2017 11:23 AM, Marc MERLIN wrote: Hi Chris, Thanks for the reply, much appreciated. On Mon, May 01, 2017 at 07:50:22PM -0600, Chris Murphy wrote: What about btfs check (no repair), without and then also with --mode=lowmem? In theory I

Re: 4.11 relocate crash, null pointer + rolling back a filesystem by X hours?

At 05/02/2017 11:23 AM, Marc MERLIN wrote: Hi Chris, Thanks for the reply, much appreciated. On Mon, May 01, 2017 at 07:50:22PM -0600, Chris Murphy wrote: What about btfs check (no repair), without and then also with --mode=lowmem? In theory I like the idea of a 24 hour rollback; but in

Re: 4.11 relocate crash, null pointer + rolling back a filesystem by X hours?

At 05/02/2017 02:08 AM, Marc MERLIN wrote: So, I forgot to mention that it's my main media and backup server that got corrupted. Yes, I do actually have a backup of a backup server, but it's going to take days to recover due to the amount of data to copy back, not counting lots of manual

Re: 4.11 relocate crash, null pointer + rolling back a filesystem by X hours?

Am Mon, 1 May 2017 22:56:06 -0600 schrieb Chris Murphy : > On Mon, May 1, 2017 at 9:23 PM, Marc MERLIN wrote: > > Hi Chris, > > > > Thanks for the reply, much appreciated. > > > > On Mon, May 01, 2017 at 07:50:22PM -0600, Chris Murphy wrote: > >> What

Re: 4.11 relocate crash, null pointer + rolling back a filesystem by X hours?

Am Tue, 2 May 2017 05:01:02 + (UTC) schrieb Duncan <1i5t5.dun...@cox.net>: > Of course on-list I'm somewhat known for my arguments propounding the > notion that any filesystem that's too big to be practically > maintained (including time necessary to restore from backups, should > that be

Re: 4.11 relocate crash, null pointer + rolling back a filesystem by X hours?

On Mon, May 01, 2017 at 10:56:06PM -0600, Chris Murphy wrote: > > Right, of course, I was being way over optimistic here. I kind of forgot > > that metadata wasn't COW, my bad. > > Well it is COW. But there's more to the file system than fs trees, and > just because an fs tree gets snapshot

Re: 4.11 relocate crash, null pointer + rolling back a filesystem by X hours?

Marc MERLIN posted on Mon, 01 May 2017 20:23:46 -0700 as excerpted: > Also, how is --mode=lowmem being useful? FWIW, I just watched your talk that's linked from the wiki, and wondered what you were doing these days as I hadn't seen any posts from you here for awhile. Well, that you're asking

Re: 4.11 relocate crash, null pointer + rolling back a filesystem by X hours?

On Mon, May 1, 2017 at 9:23 PM, Marc MERLIN wrote: > Hi Chris, > > Thanks for the reply, much appreciated. > > On Mon, May 01, 2017 at 07:50:22PM -0600, Chris Murphy wrote: >> What about btfs check (no repair), without and then also with --mode=lowmem? >> >> In theory I like the

Re: 4.11 relocate crash, null pointer + rolling back a filesystem by X hours?

Hi Chris, Thanks for the reply, much appreciated. On Mon, May 01, 2017 at 07:50:22PM -0600, Chris Murphy wrote: > What about btfs check (no repair), without and then also with --mode=lowmem? > > In theory I like the idea of a 24 hour rollback; but in normal usage > Btrfs will eventually free up

Re: 4.11 relocate crash, null pointer + rolling back a filesystem by X hours?

What about btfs check (no repair), without and then also with --mode=lowmem? In theory I like the idea of a 24 hour rollback; but in normal usage Btrfs will eventually free up space containing stale and no longer necessary metadata. Like the chunk tree, it's always changing, so you get to a

Re: 4.11 relocate crash, null pointer + rolling back a filesystem by X hours?

So, I forgot to mention that it's my main media and backup server that got corrupted. Yes, I do actually have a backup of a backup server, but it's going to take days to recover due to the amount of data to copy back, not counting lots of manual typing due to the number of subvolumes, btrfs