On 2020/1/18 9:43 下午, Clodoaldo Neto wrote:

On Sat, Jan 18, 2020 at 9:35 AM Coly Li [off-list ref] wrote:

quoted

On 2020/1/18 8:22 下午, Clodoaldo Neto wrote:

quoted

On Sat, Jan 18, 2020 at 7:54 AM Clodoaldo Neto
[off-list ref] wrote:

quoted

On Thu, Jan 16, 2020 at 9:59 PM Coly Li [off-list ref] wrote:

quoted

On 2020/1/17 5:52 上午, Clodoaldo Neto wrote:

quoted

Em seg, 13 de jan de 2020 11:19, Coly Li <colyli@suse.de
<mailto:colyli@suse.de>> escreveu:

quoted

On 2020/1/13 8:44 下午, Jens-U. Mozdzen wrote:

quoted

Hi Coly,

jumping in here, because I was looking for a way to revert from bcache
to plain device:

Zitat von Coly Li <colyli@suse.de <mailto:colyli@suse.de>>:

quoted

The super block location of the backing disk is occupied by bcache. You
cannot mount the file system directly from the backing disk which is
formated as bcache backing device [...] (bcache offset all I/Os on
bcache device 4KB behind the requesting
LBA on backing disk).

Assuming that no caching device is associated with a backing device (so
the backing device is "clean" as in "containing all data blocks with the
current content"), could one convert the content of a backing device to
a "non-bcached device" by removing the first 4096 octets of the backing
device content?

Something like "dd if=backingdev of=newdev skip_bytes=4096 ..."?

Hi Jens-U,

you may try dmsetup to setup a linear device mapper target, and the map
table just skipping the first 4KB (bcache superblock area). If you are
lucky, I mean the real file system is not corrupted, the created device
mapper target can be mounted directly.

I'm trying dmsetup but it does not accept anything other than 0 and 0
at the beginning and end of the table:

# echo '0 3774578672 linear /dev/mapper/backing-device 8' | dmsetup
create dmb
device-mapper: reload ioctl on dmb  failed: Invalid argument
Command failed.

The above line should work, if 3774578672 is a correct size number in
sectors.

I took it from the original map:

# dmsetup table /dev/mapper/backing-device
0 3774578672 crypt aes-xts-plain64
:64:logon:cryptsetup:7e2c0b40-8dec-4b13-8d00-b53b55160775-d0 0 251:0
32768

It works like this:

# echo '0 3774578664 linear /dev/mapper/backing-device 8' | dmsetup create dmb

But then I can't mount it:

# mount /dev/mapper/dmb /r
mount: /r: wrong fs type, bad option, bad superblock on
/dev/mapper/dmb, missing codepage or helper program, or other error.

It might be my fault, from bcache-tools, it seems the offset is
BDEV_DATA_START_DEFAULT (16 sectors). How about:
# echo '0 3774578656 linear /dev/mapper/backing-device 16' | dmsetup
create dmb

Still no luck

# echo '0 3774578656 linear /dev/mapper/backing-device 16' | dmsetup create dmb
# mount /dev/mapper/dmb /r
mount: /r: wrong fs type, bad option, bad superblock on
/dev/mapper/dmb, missing codepage or helper program, or other error.

The tricky part is to calculate the correct linear mapping size.

For example, I have a 500G hard drive, from fdisk I see its size is
1048576000 sectors. I use it as a bcache backing device and format an
Ext4 file system on it. Then I use the following mistaken command line
to setup a linear target to skip the first 8 sectors,
 # echo '0 1048575000  linear /dev/sdc 16' | dmsetup create dmb
Then mount /dev/mapper/dmb to /mnt fails, the kmesg hints me,
 [1884572.477316] EXT4-fs (dm-0): bad geometry: block count 131071998
exceeds size of device (131071875 blocks)

So I realize Ext4 file system will check the block device size, so I
need to provide an exact accurate length number for the linear target.
From the kmesg I see the correct sector size should be
(131071998*8=)1048575984, then I re-create the linear target by,
 # echo '0 1048575984  linear /dev/sdc 16' | dmsetup create dmb
Then I mount /dev/mapper/dmb to /mnt, it works and I have the following
line from command 'mount',
 /dev/mapper/dmb on /mnt type ext4 (rw,relatime)

I don't use the encrpyt file system and I don't know the excact detail
about it. But I guess, it might because the incorrect length number for
your dm linear target as I show by the above example.

-- 

Coly Li