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
> relatio
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 s
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 the earlier message f
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.
> >
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 tre
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 examp
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 li
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 nor
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 typing
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 about btfs check (no repair), without and t
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 nec
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 doesn'
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 t
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 idea of a 24 hour
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
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 point,
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
send/re
I have a filesystem that sadly got corrupted by a SAS card I just installed
yesterday.
I don't think in a case like this, there is there a way to roll back all
writes across all subvolumes in the last 24H, correct?
Is the best thing to go in each subvolume, delete the recent snapshots and
rename
18 matches
Mail list logo
