Chris,
The only other difference I can think of is that sdb the "first" time was
acquired by the kernel after booting. Again, the SIIG docking station. The
system "noticed" the device and udev "fixed" things up so the drive is usable.
The "second" time, sdb was already powered up.
I could powe
Chris,
No message appeared but the message came out at the beginning of btrfs-convert.
I could convert again if that would help.
dmesg for "this" boot enclosed:
Regards,
George...
On Saturday, March 6, 2021, 1:36:13 PM PST, Chris Murphy
wrote:
fdisk says:
Disk /dev/sda: 1.82 TiB,
Chris,
Scrub is still running. When it's done, I'll reboot a couple of times.
sdb is in a SIIG 3.0 USB 2x docking station. Could it be NOT passing some
device commands? I have sent a query to the developer(s) of smartmontools just
in case.
Regards,
George..
On Saturday, March 6, 2021, 1:36
fdisk says:
Disk /dev/sda: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
/dev/sda8 436217856 3907029167 3470811312 1.6T 83 Linux
sda8 is 1777055391744 bytes
Btrfs says:
dev_item.total_bytes1777055391744
Those agree. The scrub message comes from
block/blk-core.c:655: pr_info_
On Sat, Mar 6, 2021 at 1:53 PM George R Goffe wrote:
>
> [17325.282263] BTRFS warning (device sdb1): checksum error at logical
> 498744950784 on dev /dev/sdb1, physical 1415872512, root 256, inode 257,
> offset 262144, length 4096, links 1 (path: image)
> [17325.282299] BTRFS error (device sdb1)
fc35-bash 5.1 ~# btrfs inspect-internal dump-super /dev/sda8 | grep bytes
total_bytes 1777055391744
bytes_used 1771772448768
dev_item.total_bytes 1777055391744
dev_item.bytes_used 1777053872128
fc35-bash 5.1 ~# btrfs inspect-internal dump-super /dev/sdb1 | grep byt
Also need:
sudo btrfs insp dump-s /dev/sda8 | grep 'total_bytes\|dev_item.total_bytes'
sudo btrfs insp dump-s /dev/sdb1 | grep 'total_bytes\|dev_item.total_bytes'
--
Chris
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an emai
Chris,
Started scrub on sdb1 now... lots of errors. see below.
On Saturday, March 6, 2021, 12:31:02 PM PST, Chris Murphy
wrote:
On Sat, Mar 6, 2021 at 10:07 AM George R Goffe wrote:
>
> Chris,
>
> I'm trying to re-create the "beyond end of disk" problem. I have nowhere near
> enough ext
On Sat, Mar 6, 2021 at 10:07 AM George R Goffe wrote:
>
> Chris,
>
> I'm trying to re-create the "beyond end of disk" problem. I have nowhere near
> enough extra space to hold the image and tar file you've asked for AND,
> there's too much personal information for me for me to feel comfortable
Chris,
I'm trying to re-create the "beyond end of disk" problem. I have nowhere near
enough extra space to hold the image and tar file you've asked for AND, there's
too much personal information for me for me to feel comfortable posting it
publicly.
I'm converting a smaller drive now and see a
On Fri, Mar 5, 2021 at 10:39 AM Chris Murphy wrote:
>
> Quick follow up on one thing I can't reproduce from George's scrub:
>
> [36365.549230] BTRFS error (device sda8): scrub: tree block
> 1777055424512 spanning stripes, ignored. logical=1777055367168
> [36365.549262] attempt to access beyond end
Quick follow up on one thing I can't reproduce from George's scrub:
[36365.549230] BTRFS error (device sda8): scrub: tree block
1777055424512 spanning stripes, ignored. logical=1777055367168
[36365.549262] attempt to access beyond end of device
sda8: rw=0, want=3470811376, limit=347
On 3/4/21 6:50 AM, Matthew Miller wrote:
On Wed, Mar 03, 2021 at 05:40:19PM -0800, Samuel Sieb wrote:
There are a few different types of full-disk backup, but if it's
file-based and the atimes are modified, that's the intent of the
backup process. The atimes are used to determine which files to
On Thu, Mar 4, 2021 at 9:50 AM Matthew Miller wrote:
>
> On Wed, Mar 03, 2021 at 05:40:19PM -0800, Samuel Sieb wrote:
> > There are a few different types of full-disk backup, but if it's
> > file-based and the atimes are modified, that's the intent of the
> > backup process. The atimes are used t
On Wed, Mar 03, 2021 at 05:40:19PM -0800, Samuel Sieb wrote:
> There are a few different types of full-disk backup, but if it's
> file-based and the atimes are modified, that's the intent of the
> backup process. The atimes are used to determine which files to
> backup. A scrub is not a backup an
George,
You've found a bug. I've got a reproducer.
https://github.com/kdave/btrfs-progs/issues/349
Both the ext4 rollback file, ext2_saved/image, and the converted btrfs
file system are OK. The corruption is bogus, so the bug is that
somehow checksums on a handful of specific blocks (not random)
On Wed, Mar 3, 2021 at 5:34 PM Matthew Miller wrote:
>
> On Wed, Mar 03, 2021 at 04:57:28PM -0700, Chris Murphy wrote:
> > It works at the block level. A block is read, checksum calculated and
> > compared to the previously recorded checksum for the block. It doesn't
> > know what it's reading, no
On 3/3/21 4:34 PM, Matthew Miller wrote:
On Wed, Mar 03, 2021 at 12:13:33PM -0800, Samuel Sieb wrote:
It depends on how the scrubbing works. I would have expected it to
be reading data at the filesystem level, not actually opening and
reading every file. That seems like a really bad thing to m
On Wed, Mar 03, 2021 at 12:13:33PM -0800, Samuel Sieb wrote:
> It depends on how the scrubbing works. I would have expected it to
> be reading data at the filesystem level, not actually opening and
> reading every file. That seems like a really bad thing to me,
> resetting the atimes on every fil
On Wed, Mar 03, 2021 at 04:57:28PM -0700, Chris Murphy wrote:
> It works at the block level. A block is read, checksum calculated and
> compared to the previously recorded checksum for the block. It doesn't
> know what it's reading, not even whether it's compressed or not. It
> just becomes a strea
On Wed, Mar 3, 2021 at 1:14 PM Samuel Sieb wrote:
>
> On 3/3/21 10:05 AM, Matthew Miller wrote:
> > On Wed, Mar 03, 2021 at 11:56:58AM -0600, Richard Shaw wrote:
> >> From what I can tell scrubbing only reads data and compares to the stored
> >> checksum. Why would that wear out a SSD?
> >
> > If
On Wed, Mar 3, 2021 at 10:34 AM George R Goffe wrote:
>
> Chris,
>
> Here's the information you requested.
>
> I'm wondering just how this happened. One of the messages refers to "beyond
> end of device". I'm alarmed.
Don't panic.
But do keep your backups fresh, while you have the chance.
What
On 3/3/21 10:05 AM, Matthew Miller wrote:
On Wed, Mar 03, 2021 at 11:56:58AM -0600, Richard Shaw wrote:
From what I can tell scrubbing only reads data and compares to the stored
checksum. Why would that wear out a SSD?
If you have atimes enabled, reading a file also makes a metadata write. Bu
On Wed, Mar 03, 2021 at 11:56:58AM -0600, Richard Shaw wrote:
> From what I can tell scrubbing only reads data and compares to the stored
> checksum. Why would that wear out a SSD?
If you have atimes enabled, reading a file also makes a metadata write. But
I don't think it's that big a deal on mod
On Tue, Feb 23, 2021 at 3:26 PM pmkel...@frontier.com
wrote:
> I recall a long and detailed discussion on this list before F33 was
> released concerning what disk maintenance would be required with BTRFS.
> As I recall, the final word was along the lines the running Scrub and
> the other BTRFS ut
Chris,
Here's the information you requested.
I'm wondering just how this happened. One of the messages refers to "beyond end
of device". I'm alarmed.
Regards,
George...
[ 2017.474378] BTRFS info (device sda8): scrub: started on devid 1
[ 2101.646773] BTRFS warning (device sda8): checksum erro
On 2/23/21 10:58, Matthew Miller wrote:
On Tue, Feb 23, 2021 at 10:18:13AM -0500, Neal Gompa wrote:
sudo btrfs scrub start /mnt
It's kind of unfortunate that we also have a command (in the distro since
2007) called just "scrub" which will destroy al of your data. :-/
Not going to lie, it to
On Tue, Feb 23, 2021 at 10:18:13AM -0500, Neal Gompa wrote:
> > > sudo btrfs scrub start /mnt
> > It's kind of unfortunate that we also have a command (in the distro since
> > 2007) called just "scrub" which will destroy al of your data. :-/
>
> Not going to lie, it took three tries to read this t
On Tue, Feb 23, 2021 at 10:03 AM Matthew Miller
wrote:
>
> On Mon, Feb 22, 2021 at 02:58:00PM -0700, Chris Murphy wrote:
> > We should find out if there's more widespread corruption. The basic
> > command to scrub that particular Btrfs file system is:
> >
> > sudo btrfs scrub start /mnt
>
> It's k
On Mon, Feb 22, 2021 at 02:58:00PM -0700, Chris Murphy wrote:
> We should find out if there's more widespread corruption. The basic
> command to scrub that particular Btrfs file system is:
>
> sudo btrfs scrub start /mnt
It's kind of unfortunate that we also have a command (in the distro since
20
On Mon, Feb 22, 2021 at 1:39 AM George R Goffe wrote:
> Feb 21 18:55:38 fc35 kernel: BTRFS warning (device sda8): csum failed root
> 256 ino 257 off 0 csum 0xe05b8b2e expected csum 0xc90f1f63 mirror 1
> Feb 21 18:55:38 fc35 kernel: BTRFS error (device sda8): bdev /dev/sda8 errs:
> wr 0, rd 0, f
Chris,
I tried some commands and captured what /var/log/message "said" about each. I'm
somewhat alarmed that these errors somehow crept into the image. There were NO
outages or interruptions during the conversion. smartctl doesn't "say" anything
about drive problems either... hence the alarm.
On Sun, Feb 21, 2021 at 4:16 PM George R Goffe wrote:
>> On Sunday, February 21, 2021, 1:48:52 PM PST, Chris Murphy
>> wrote:
> That works for me. But you could alternatively try:
>
> mount /dev/vdb /mnt/btrfs
> losetup -r /dev/loop0 /mnt/btrfs/ext2_saved/image
> # losetup
> NAME SIZELI
Chris,
/ext2_saved and /ext4 are in / but only temporarily.
I have "inlined" my responses prefixed with '#' below (is this ok to do?)
George...
On Sunday, February 21, 2021, 1:48:52 PM PST, Chris Murphy
wrote:
On Sun, Feb 21, 2021 at 2:34 PM Chris Murphy wrote:
>
> On Sun, Feb 21, 2021 at
On Sun, Feb 21, 2021 at 2:21 PM Samuel Sieb wrote:
> > fc35-bash 5.1 ~# mount -t ext4 -o loop,ro /ext2_saved/image /ext4
> > mount: /ext4: can't read superblock on /dev/loop0.
>
> I don't know much about btrfs, but what does "file /ext2_saved/image" say?
Good idea.
# file /mnt/btrfs/ext2_saved/
Chris,
Thanks for responding.
I'm pretty sure it was after conversion.
George...
On Sunday, February 21, 2021, 1:27:12 PM PST, Chris Murphy
wrote:
On Sun, Feb 21, 2021 at 2:16 PM George R Goffe via test
wrote:
>
> Hi,
>
> I have converted a large ext4 filesystem to btrfs and by a
On Sun, Feb 21, 2021 at 2:34 PM Chris Murphy wrote:
>
> On Sun, Feb 21, 2021 at 2:16 PM George R Goffe via test
> wrote:
> >
> > fc35-bash 5.1 ~# mount -t ext4 -o loop,ro /ext2_saved/image /ext4
> > mount: /ext4: can't read superblock on /dev/loop0.
>
> Hmm. That's unexpected though. I'm going to
On Sun, Feb 21, 2021 at 2:16 PM George R Goffe via test
wrote:
>
> fc35-bash 5.1 ~# mount -t ext4 -o loop,ro /ext2_saved/image /ext4
> mount: /ext4: can't read superblock on /dev/loop0.
Hmm. That's unexpected though. I'm going to try it in a VM. It should work.
--
Chris Murphy
___
On Sun, Feb 21, 2021 at 2:16 PM George R Goffe via test
wrote:
>
> Hi,
>
> I have converted a large ext4 filesystem to btrfs and by accident deleted an
> important users home directory. Reading btrfs doc seems to imply that the
> directory can be recovered without reverting the filesystem to ext
On 2/21/21 1:15 PM, George R Goffe via test wrote:
I have converted a large ext4 filesystem to btrfs and by accident deleted an
important users home directory. Reading btrfs doc seems to imply that the
directory can be recovered without reverting the filesystem to ext4.
First, you should neve
40 matches
Mail list logo
