Re: So, wipe it out and start over or keep debugging?
On 2015-08-18 17:09, Chris Murphy wrote: On Tue, Aug 18, 2015 at 5:21 AM, Austin S Hemmelgarn ahferro...@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. smime.p7s Description: S/MIME Cryptographic Signature
Re: So, wipe it out and start over or keep debugging?
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. smime.p7s Description: S/MIME Cryptographic Signature
Re: So, wipe it out and start over or keep debugging?
I was doing it on an unmounted volume anyhow. On Tue, Aug 18, 2015 at 5:09 PM, Chris Murphy li...@colorremedies.com wrote: On Tue, Aug 18, 2015 at 5:21 AM, Austin S Hemmelgarn ahferro...@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 -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: So, wipe it out and start over or keep debugging?
On Tue, Aug 18, 2015 at 5:21 AM, Austin S Hemmelgarn ahferro...@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 -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: So, wipe it out and start over or keep debugging?
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 theo...@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 ahferro...@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 -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: So, wipe it out and start over or keep debugging?
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 ahferro...@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 -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: So, wipe it out and start over or keep debugging?
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). smime.p7s Description: S/MIME Cryptographic Signature
Re: So, wipe it out and start over or keep debugging?
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. smime.p7s Description: S/MIME Cryptographic Signature
Re: So, wipe it out and start over or keep debugging?
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 ahferro...@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 -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
So, wipe it out and start over or keep debugging?
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 -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
