So, wipe it out and start over or keep debugging?

So, wipe it out and start over or keep debugging?

[Timothy Normand Miller]

To those of you who have been helping out with my 4-drive RAID1
situation, is there anything further we should do to investigate this,
in case we can uncover any more bugs, or should I just wipe everything
out and restore from backup?

-- 
Timothy Normand Miller, PhD
Assistant Professor of Computer Science, Binghamton University
http://www.cs.binghamton.edu/~millerti/
Open Graphics Project

Re: So, wipe it out and start over or keep debugging?

[Austin S Hemmelgarn]

[-- Attachment #1: Type: text/plain, Size: 592 bytes --]

On 2015-08-15 17:46, Timothy Normand Miller wrote:
> To those of you who have been helping out with my 4-drive RAID1
> situation, is there anything further we should do to investigate this,
> in case we can uncover any more bugs, or should I just wipe everything
> out and restore from backup?
>
If you need the system back online, then my suggestion would be to use 
btrfs-image to get metadata images of the disks (there's an option to 
clear out private data if need be), and then restore from backup.  That 
way, we still have the problematic images to work with and examine.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]

Re: So, wipe it out and start over or keep debugging?

[Timothy Normand Miller]

I'm not sure if I'm doing this wrong.  Here's what I'm seeing:

# btrfs-image -c9 -t4 -w /mnt/btrfs ~/btrfs_dump.z
Superblock bytenr is larger than device size
Open ctree failed
create failed (No such file or directory)


On Mon, Aug 17, 2015 at 7:43 AM, Austin S Hemmelgarn
<ahferroin7@gmail.com> wrote:
> On 2015-08-15 17:46, Timothy Normand Miller wrote:
>>
>> To those of you who have been helping out with my 4-drive RAID1
>> situation, is there anything further we should do to investigate this,
>> in case we can uncover any more bugs, or should I just wipe everything
>> out and restore from backup?
>>
> If you need the system back online, then my suggestion would be to use
> btrfs-image to get metadata images of the disks (there's an option to clear
> out private data if need be), and then restore from backup.  That way, we
> still have the problematic images to work with and examine.
>



-- 
Timothy Normand Miller, PhD
Assistant Professor of Computer Science, Binghamton University
http://www.cs.binghamton.edu/~millerti/
Open Graphics Project

Re: So, wipe it out and start over or keep debugging?

[Austin S Hemmelgarn]

[-- Attachment #1: Type: text/plain, Size: 564 bytes --]

On 2015-08-17 14:52, Timothy Normand Miller wrote:
> I'm not sure if I'm doing this wrong.  Here's what I'm seeing:
>
> # btrfs-image -c9 -t4 -w /mnt/btrfs ~/btrfs_dump.z
> Superblock bytenr is larger than device size
> Open ctree failed
> create failed (No such file or directory)

For the source, you need to specify the underlying block device, not the 
top of the mounted filesystem.  It's trying to read the directory as a 
block device and getting very confused.  We should probably add some 
kind of check to btrfs-image to warn about that.



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]

Re: So, wipe it out and start over or keep debugging?

[Timothy Normand Miller]

In that case, do I need to do all four block devices separately, or
will the tool figure it out?

On Tue, Aug 18, 2015 at 7:21 AM, Austin S Hemmelgarn
<ahferroin7@gmail.com> wrote:
> On 2015-08-17 14:52, Timothy Normand Miller wrote:
>>
>> I'm not sure if I'm doing this wrong.  Here's what I'm seeing:
>>
>> # btrfs-image -c9 -t4 -w /mnt/btrfs ~/btrfs_dump.z
>> Superblock bytenr is larger than device size
>> Open ctree failed
>> create failed (No such file or directory)
>
>
> For the source, you need to specify the underlying block device, not the top
> of the mounted filesystem.  It's trying to read the directory as a block
> device and getting very confused.  We should probably add some kind of check
> to btrfs-image to warn about that.
>
>



-- 
Timothy Normand Miller, PhD
Assistant Professor of Computer Science, Binghamton University
http://www.cs.binghamton.edu/~millerti/
Open Graphics Project

Re: So, wipe it out and start over or keep debugging?

[Timothy Normand Miller]

I ran the following command.  It spent a lot of time creating a
1672450048 byte file.  Then it stopped writing to the file and started
using 100% CPU.  It's currently doing no I/O, and it's been doing that
for a while now.  Is that supposed to happen?

On Tue, Aug 18, 2015 at 9:30 AM, Timothy Normand Miller
<theosib@gmail.com> wrote:
> In that case, do I need to do all four block devices separately, or
> will the tool figure it out?
>
> On Tue, Aug 18, 2015 at 7:21 AM, Austin S Hemmelgarn
> <ahferroin7@gmail.com> wrote:
>> On 2015-08-17 14:52, Timothy Normand Miller wrote:
>>>
>>> I'm not sure if I'm doing this wrong.  Here's what I'm seeing:
>>>
>>> # btrfs-image -c9 -t4 -w /mnt/btrfs ~/btrfs_dump.z
>>> Superblock bytenr is larger than device size
>>> Open ctree failed
>>> create failed (No such file or directory)
>>
>>
>> For the source, you need to specify the underlying block device, not the top
>> of the mounted filesystem.  It's trying to read the directory as a block
>> device and getting very confused.  We should probably add some kind of check
>> to btrfs-image to warn about that.
>>
>>
>
>
>
> --
> Timothy Normand Miller, PhD
> Assistant Professor of Computer Science, Binghamton University
> http://www.cs.binghamton.edu/~millerti/
> Open Graphics Project



-- 
Timothy Normand Miller, PhD
Assistant Professor of Computer Science, Binghamton University
http://www.cs.binghamton.edu/~millerti/
Open Graphics Project

Re: So, wipe it out and start over or keep debugging?

[Austin S Hemmelgarn]

[-- Attachment #1: Type: text/plain, Size: 829 bytes --]

On 2015-08-18 11:10, Timothy Normand Miller wrote:
> I ran the following command.  It spent a lot of time creating a
> 1672450048 byte file.  Then it stopped writing to the file and started
> using 100% CPU.  It's currently doing no I/O, and it's been doing that
> for a while now.  Is that supposed to happen?
>
Not normally, I've seen this happen sometimes before for a short period 
when it hits a group of blocks that don't compress well, but that 
usually goes away after a few seconds.  I think this is probably a bug. 
  However, it isn't unusual for a big filesystem to have a really small 
image produced if it contains mostly big files (btrfs-image just copies 
the metadata, not the actual file data, so even without compression, it 
usually will take up less space than the filesystem being imaged).



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]

Re: So, wipe it out and start over or keep debugging?

[Chris Murphy]

On Tue, Aug 18, 2015 at 5:21 AM, Austin S Hemmelgarn
<ahferroin7@gmail.com> wrote:
> On 2015-08-17 14:52, Timothy Normand Miller wrote:
>>
>> I'm not sure if I'm doing this wrong.  Here's what I'm seeing:
>>
>> # btrfs-image -c9 -t4 -w /mnt/btrfs ~/btrfs_dump.z
>> Superblock bytenr is larger than device size
>> Open ctree failed
>> create failed (No such file or directory)
>
>
> For the source, you need to specify the underlying block device, not the top
> of the mounted filesystem.  It's trying to read the directory as a block
> device and getting very confused.  We should probably add some kind of check
> to btrfs-image to warn about that.

Should it even be possible to use btrfs-image on a mounted volume? If
it's written to at all, the collected image is going to be
inconsistent.

-- 
Chris Murphy

Re: So, wipe it out and start over or keep debugging?

[Timothy Normand Miller]

I was doing it on an unmounted volume anyhow.

On Tue, Aug 18, 2015 at 5:09 PM, Chris Murphy <lists@colorremedies.com> wrote:
> On Tue, Aug 18, 2015 at 5:21 AM, Austin S Hemmelgarn
> <ahferroin7@gmail.com> wrote:
>> On 2015-08-17 14:52, Timothy Normand Miller wrote:
>>>
>>> I'm not sure if I'm doing this wrong.  Here's what I'm seeing:
>>>
>>> # btrfs-image -c9 -t4 -w /mnt/btrfs ~/btrfs_dump.z
>>> Superblock bytenr is larger than device size
>>> Open ctree failed
>>> create failed (No such file or directory)
>>
>>
>> For the source, you need to specify the underlying block device, not the top
>> of the mounted filesystem.  It's trying to read the directory as a block
>> device and getting very confused.  We should probably add some kind of check
>> to btrfs-image to warn about that.
>
> Should it even be possible to use btrfs-image on a mounted volume? If
> it's written to at all, the collected image is going to be
> inconsistent.
>
> --
> Chris Murphy



-- 
Timothy Normand Miller, PhD
Assistant Professor of Computer Science, Binghamton University
http://www.cs.binghamton.edu/~millerti/
Open Graphics Project

Re: So, wipe it out and start over or keep debugging?

[Austin S Hemmelgarn]

[-- Attachment #1: Type: text/plain, Size: 1125 bytes --]

On 2015-08-18 17:09, Chris Murphy wrote:
> On Tue, Aug 18, 2015 at 5:21 AM, Austin S Hemmelgarn
> <ahferroin7@gmail.com> wrote:
>> On 2015-08-17 14:52, Timothy Normand Miller wrote:
>>>
>>> I'm not sure if I'm doing this wrong.  Here's what I'm seeing:
>>>
>>> # btrfs-image -c9 -t4 -w /mnt/btrfs ~/btrfs_dump.z
>>> Superblock bytenr is larger than device size
>>> Open ctree failed
>>> create failed (No such file or directory)
>>
>>
>> For the source, you need to specify the underlying block device, not the top
>> of the mounted filesystem.  It's trying to read the directory as a block
>> device and getting very confused.  We should probably add some kind of check
>> to btrfs-image to warn about that.
>
> Should it even be possible to use btrfs-image on a mounted volume? If
> it's written to at all, the collected image is going to be
> inconsistent.
>
In theory, it might be useful, but we would need to slap a big obnoxious 
warning on such functionality.  I don't think it's possible right now, 
and as such we should do something to account for the possibility of 
someone trying it.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]