On Sep 11, 2014, at 11:19 PM, Russell Coker wrote:
> It would be nice if a file system mounted ro counted as ro snapshots for
> btrfs send.
>
> When a file system is so messed up it can't be mounted rw it should be
> regarded as ro for all operations.
Yes it's come up before, and there's a q
Chris Murphy posted on Thu, 11 Sep 2014 20:10:26 -0600 as excerpted:
> Sure. But what's the next step? Given 260+ snapshots might mean well
> more than 350GB of data, depending on how deduplicated the fs is, it
> still probably would be faster to rsync this to a pile of drives in
> linear/concat+X
Chris Murphy posted on Thu, 11 Sep 2014 20:10:26 -0600 as excerpted:
> And then when I think about just creating a new fs, using btrfs
> send/receive, the snapshots need to be ro first.
FWIW, at this point I'd forget about send/receive and create the backup
(assuming one doesn't exist already) u
Russell Coker posted on Fri, 12 Sep 2014 15:19:04 +1000 as excerpted:
> It would be nice if a file system mounted ro counted as ro snapshots for
> btrfs send.
>
> When a file system is so messed up it can't be mounted rw it should be
> regarded as ro for all operations.
Indeed, and that has been
It would be nice if a file system mounted ro counted as ro snapshots for btrfs
send.
When a file system is so messed up it can't be mounted rw it should be regarded
as ro for all operations.
--
Sent from my Samsung Galaxy Note 2 with K-9 Mail.
--
To unsubscribe from this list: send the line "un
On Sep 11, 2014, at 5:51 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> Chris Murphy posted on Thu, 11 Sep 2014 15:25:51 -0600 as excerpted:
>
>> On Sep 11, 2014, at 1:31 PM, Duncan <1i5t5.dun...@cox.net> wrote:
>>>
>>> I wouldn't try defragging now, but it might be worthwhile to stop the
>>> devic
Chris Murphy posted on Thu, 11 Sep 2014 15:25:51 -0600 as excerpted:
> On Sep 11, 2014, at 1:31 PM, Duncan <1i5t5.dun...@cox.net> wrote:
>>
>> I wouldn't try defragging now, but it might be worthwhile to stop the
>> device delete (rebooting to do so since I don't think there's a cancel)
>
> 'btr
After a disk died and was replaced, "btrfs device delete missing" is
taking more than 10 days on an otherwise idle server:
Something isn't right though, because it's clearly neither reading nor
writing at \
anywhere close to 1/2 the drive read throughput. I'm curious what
'iotop -d30 -o' \
sho
On Sep 11, 2014, at 1:31 PM, Duncan <1i5t5.dun...@cox.net> wrote:
>
> I wouldn't try defragging now, but it might be worthwhile to stop the
> device delete (rebooting to do so since I don't think there's a cancel)
'btrfs replace cancel' does exist, although I haven't tried it.
Something isn't r
Tomasz Chmielewski posted on Thu, 11 Sep 2014 17:22:15 +0200 as excerpted:
> After a disk died and was replaced, "btrfs device delete missing" is
> taking more than 10 days on an otherwise idle server:
>
> # btrfs fi show /home
> Label: none uuid: 84d087aa-3a32-46da-844f-a233237cf04f
>
After a disk died and was replaced, "btrfs device delete missing" is
taking more than 10 days on an otherwise idle server:
# btrfs fi show /home
Label: none uuid: 84d087aa-3a32-46da-844f-a233237cf04f
Total devices 3 FS bytes used 362.44GiB
devid2 size 1.71TiB used 365.03GiB
11 matches
Mail list logo
