On Mon, Oct 08, 2018 at 02:03:44AM +0200, Hans van Kranenburg wrote:
> And yes, when promoting things like the new show_usage example to
> programs that are easily available, users will probably start parsing
> the output of them with sed and awk which is a total abomination and the
> absolute
Hi,
On 09/24/2018 01:19 AM, Adam Borowski wrote:
> On Sun, Sep 23, 2018 at 11:54:12PM +0200, Hans van Kranenburg wrote:
>> Two examples have been added, which use the new code. I would appreciate
>> extra testing. Please try them and see if the reported numbers make sense:
>>
>>
On Wed, Sep 26, 2018 at 12:08:56PM +0800, Anand Jain wrote:
>
>
> On 09/25/2018 06:54 PM, Nikolay Borisov wrote:
> >
> >
> > On 25.09.2018 07:24, Anand Jain wrote:
> > > Open code helps to grep and find out parameter sent to the
> > > _scratch_mkfs_sized here.
> > >
> > > Signed-off-by: Anand
The Prometheus statistics collection/aggregation/monitoring/alerting system
[1] is quite popular, easy to use and will probably be the basis for the
upcoming OpenMetrics "standard" [2].
Prometheus collects metrics by polling host-local "exporters" that respond
to http requests; many such
Thanks for looking at it for me, appreciate the input.
On Sun, Oct 7, 2018 at 2:25 PM evan d wrote:
>
> > > I may as well use wipefs to clear crud from both drives, partition and
> > > format them and then use them elsewhere. -- this more or less
> > > accurately summarise the situation?
> >
>
> > I may as well use wipefs to clear crud from both drives, partition and
> > format them and then use them elsewhere. -- this more or less
> > accurately summarise the situation?
>
> Unfortunately, yes.
I recall the machine these drives were in lost the onboard NIC when
the desktop switch it
On 2018/10/7 下午6:39, evan d wrote:
>>> like so?:
>>> grep -obUaP "\x5F\x42\x48\x52\x66\x53\x5F\x4D" /dev/sdc
>>>
>> Yes. And it will be very slow, since you're going to read out the whole
>> disk.
>>
>> But I don't really think you would get some hit, according to current
>> result.
>
> Ok, so
> > like so?:
> > grep -obUaP "\x5F\x42\x48\x52\x66\x53\x5F\x4D" /dev/sdc
> >
> Yes. And it will be very slow, since you're going to read out the whole
> disk.
>
> But I don't really think you would get some hit, according to current
> result.
Ok, so it is what it is. Based on what you're
On 2018/10/7 下午4:28, evan d wrote:
# dd if=/dev/sdb bs=1M of=last_chance.raw count=128 skip=256M
# grep -obUaP "\x5F\x42\x48\x52\x66\x53\x5F\x4D" last_chance.raw
>
> grep returns no result on either drive
>
> If still no hit, you could try just run the grep command on the disk.
>
> >> # dd if=/dev/sdb bs=1M of=last_chance.raw count=128 skip=256M
> >> # grep -obUaP "\x5F\x42\x48\x52\x66\x53\x5F\x4D" last_chance.raw
grep returns no result on either drive
If still no hit, you could try just run the grep command on the disk.
like so?:
grep -obUaP
On 2018/10/7 下午4:09, evan d wrote:
>> If first 128M doesn't hit, I highly doubt something more strange happened.
>
> Not sure I follow, do you mean if it doesn't hit then it's likely
> something else went wrong?
Yes.
If it's just a simple offset, it should hit.
If it's some simple corruption
> If first 128M doesn't hit, I highly doubt something more strange happened.
Not sure I follow, do you mean if it doesn't hit then it's likely
something else went wrong?
> I'm considering something like encryption.
> Maybe the disk is already encrypted by hardware?
The drives were never
On 2018/10/7 下午2:47, evan d wrote:
>> None of your super blocks has correct magic.
>
>
> I take it this applies to both drives?
Yes, both drivers have something wrong.
>
>
>
>> This means either your whole disk get corrupted, or something introduced
>> some offset.
>>
>> Please try the
> None of your super blocks has correct magic.
I take it this applies to both drives?
> This means either your whole disk get corrupted, or something introduced
> some offset.
>
> Please try the following commands to dump more data around super blocks,
> so we could be able to find the
On 2018/10/7 下午2:10, evan d wrote:
>> Please try "btrfs ins dump-super -fFa" on these two disks.
>>
>> If it's only the primary superblock corrupted, the backup should be good.
>>
>> If backup is also corrupted, either it has some offset or the whole data
>> is corrupted.
>
> # btrfs ins
> Please try "btrfs ins dump-super -fFa" on these two disks.
>
> If it's only the primary superblock corrupted, the backup should be good.
>
> If backup is also corrupted, either it has some offset or the whole data
> is corrupted.
# btrfs ins dump-super -fFa /dev/sdb
superblock: bytenr=65536,
> Did you try a btrfs device scan ?
Tried it, it returns nothing.
17 matches
Mail list logo
