Hi to all, I have a hard drive encrypted using the gnome disk utility and it is formated with with btrfs and GUID, the problem started when moving a 4gb file to other disk it stooped saying input output error I think, then when I tried to access it I entered the password to decrypt and it now says that I must specify filesystem type so it doesn''t recognize the filesystem, I used 3.0 kernel, meanwhile I upgraded to 3.1, I have a backup of important files in other disk the problem is that it is also encrypted and it has btrfs so I don''t touch it for now, can anyone help here? -- Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
810d4rk wrote (ao):> Hi to all, I have a hard drive encrypted using the gnome disk utility > and it is formated with with btrfs and GUID, the problem started when > moving a 4gb file to other disk it stooped saying input output error I > think, then when I tried to access it I entered the password to > decrypt and it now says that I must specify filesystem type so it > doesn''t recognize the filesystem, I used 3.0 kernel, meanwhile I > upgraded to 3.1, I have a backup of important files in other disk the > problem is that it is also encrypted and it has btrfs so I don''t touch > it for now, can anyone help here?dd that backup disk to another disk, so you have a backup of your backup, and work with that. You can also post the dmesg output you get when you mount the broken filesystem, and ask the experts if it might be worth to try experimental btrfs.fsck on it. Sander fwiw, I backup to gpg encrypted files stored on ext4 to cope with regressions in both btrfs and disk encryption. -- Humilis IT Services and Solutions http://www.humilis.net -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> dd that backup disk to another disk, so you have a backup of your > backup, and work with that.OK.> You can also post the dmesg output you get when you mount the broken > filesystem, and ask the experts if it might be worth to try experimental > btrfs.fsck on it.dmesg does not output anything of value since the file system is not detectable, here is the kernel output: [ 4834.149123] usb 2-1.1: new high speed USB device number 12 using ehci_hcd [ 4834.245114] scsi20 : usb-storage 2-1.1:1.0 [ 4835.246193] scsi 20:0:0:0: Direct-Access WDC WD75 00BPVT-22HXZT1 1A01 PQ: 0 ANSI: 2 CCS [ 4835.317195] sd 20:0:0:0: Attached scsi generic sg4 type 0 [ 4835.317889] sd 20:0:0:0: [sdc] 1465149168 512-byte logical blocks: (750 GB/698 GiB) [ 4835.318944] sd 20:0:0:0: [sdc] Write Protect is off [ 4835.318956] sd 20:0:0:0: [sdc] Mode Sense: 00 38 00 00 [ 4835.320603] sd 20:0:0:0: [sdc] Asking for cache data failed [ 4835.320619] sd 20:0:0:0: [sdc] Assuming drive cache: write through [ 4835.324143] sd 20:0:0:0: [sdc] Asking for cache data failed [ 4835.324153] sd 20:0:0:0: [sdc] Assuming drive cache: write through [ 4836.894263] sdc: sdc1 [ 4836.897190] sd 20:0:0:0: [sdc] Asking for cache data failed [ 4836.897200] sd 20:0:0:0: [sdc] Assuming drive cache: write through [ 4836.897206] sd 20:0:0:0: [sdc] Attached SCSI disk [ 4844.803652] EXT3-fs (dm-1): error: can''t find ext3 filesystem on dev dm-1. [ 4844.856054] EXT2-fs (dm-1): error: can''t find an ext2 filesystem on dev dm-1. [ 4844.902679] EXT4-fs (dm-1): VFS: Can''t find ext4 filesystem [ 4932.637108] EXT3-fs (dm-1): error: can''t find ext3 filesystem on dev dm-1. [ 4932.686841] EXT2-fs (dm-1): error: can''t find an ext2 filesystem on dev dm-1. [ 4932.738999] EXT4-fs (dm-1): VFS: Can''t find ext4 filesystem [ 4949.142867] EXT3-fs (dm-1): error: can''t find ext3 filesystem on dev dm-1. [ 4949.197596] EXT2-fs (dm-1): error: can''t find an ext2 filesystem on dev dm-1. [ 4949.241721] EXT4-fs (dm-1): VFS: Can''t find ext4 filesystem> fwiw, I backup to gpg encrypted files stored on ext4 to cope with > regressions in both btrfs and disk encryption.In my experience btrfs + encryption eats the data, this is not the first time I had this problem with btrfs so I am considering switching to ext4, but can I still get the other data back on the broken btrfs?? -- Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Now when I tried to mount the disk I get this: Error mounting: mount exited with exit code 12: NTFS signature is missing. Failed to mount ''/dev/mapper/udisks-luks-uuid-269300fe-1329-42f8-b7fa-4a399a71d56f-uid1000'': Invalid argument The device ''/dev/mapper/udisks-luks-uuid-269300fe-1329-42f8-b7fa-4a399a71d56f-uid1000'' doesn''t seem to have a valid NTFS. Maybe the wrong device is used? Or the whole disk instead of a partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around? Can anyone help? On 23/11/2011, 810d4rk <810d4rk@gmail.com> wrote:>> dd that backup disk to another disk, so you have a backup of your >> backup, and work with that. > > OK. > >> You can also post the dmesg output you get when you mount the broken >> filesystem, and ask the experts if it might be worth to try experimental >> btrfs.fsck on it. > > dmesg does not output anything of value since the file system is not > detectable, here is the kernel output: > > [ 4834.149123] usb 2-1.1: new high speed USB device number 12 using > ehci_hcd > [ 4834.245114] scsi20 : usb-storage 2-1.1:1.0 > [ 4835.246193] scsi 20:0:0:0: Direct-Access WDC WD75 > 00BPVT-22HXZT1 1A01 PQ: 0 ANSI: 2 CCS > [ 4835.317195] sd 20:0:0:0: Attached scsi generic sg4 type 0 > [ 4835.317889] sd 20:0:0:0: [sdc] 1465149168 512-byte logical blocks: > (750 GB/698 GiB) > [ 4835.318944] sd 20:0:0:0: [sdc] Write Protect is off > [ 4835.318956] sd 20:0:0:0: [sdc] Mode Sense: 00 38 00 00 > [ 4835.320603] sd 20:0:0:0: [sdc] Asking for cache data failed > [ 4835.320619] sd 20:0:0:0: [sdc] Assuming drive cache: write through > [ 4835.324143] sd 20:0:0:0: [sdc] Asking for cache data failed > [ 4835.324153] sd 20:0:0:0: [sdc] Assuming drive cache: write through > [ 4836.894263] sdc: sdc1 > [ 4836.897190] sd 20:0:0:0: [sdc] Asking for cache data failed > [ 4836.897200] sd 20:0:0:0: [sdc] Assuming drive cache: write through > [ 4836.897206] sd 20:0:0:0: [sdc] Attached SCSI disk > [ 4844.803652] EXT3-fs (dm-1): error: can''t find ext3 filesystem on dev > dm-1. > [ 4844.856054] EXT2-fs (dm-1): error: can''t find an ext2 filesystem on dev > dm-1. > [ 4844.902679] EXT4-fs (dm-1): VFS: Can''t find ext4 filesystem > [ 4932.637108] EXT3-fs (dm-1): error: can''t find ext3 filesystem on dev > dm-1. > [ 4932.686841] EXT2-fs (dm-1): error: can''t find an ext2 filesystem on dev > dm-1. > [ 4932.738999] EXT4-fs (dm-1): VFS: Can''t find ext4 filesystem > [ 4949.142867] EXT3-fs (dm-1): error: can''t find ext3 filesystem on dev > dm-1. > [ 4949.197596] EXT2-fs (dm-1): error: can''t find an ext2 filesystem on dev > dm-1. > [ 4949.241721] EXT4-fs (dm-1): VFS: Can''t find ext4 filesystem > >> fwiw, I backup to gpg encrypted files stored on ext4 to cope with >> regressions in both btrfs and disk encryption. > > > In my experience btrfs + encryption eats the data, this is not the > first time I had this problem with btrfs so I am considering switching > to ext4, but can I still get the other data back on the broken btrfs?? > > -- > Thanks >-- Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 23 Nov 2011 19:38:37 +0000 810d4rk <810d4rk@gmail.com> wrote:> [ 4836.897206] sd 20:0:0:0: [sdc] Attached SCSI disk > [ 4844.803652] EXT3-fs (dm-1): error: can''t find ext3 filesystem on dev dm-1. > [ 4844.856054] EXT2-fs (dm-1): error: can''t find an ext2 filesystem on dev dm-1. > [ 4844.902679] EXT4-fs (dm-1): VFS: Can''t find ext4 filesystem > [ 4932.637108] EXT3-fs (dm-1): error: can''t find ext3 filesystem on dev dm-1. > [ 4932.686841] EXT2-fs (dm-1): error: can''t find an ext2 filesystem on dev dm-1. > [ 4932.738999] EXT4-fs (dm-1): VFS: Can''t find ext4 filesystem > [ 4949.142867] EXT3-fs (dm-1): error: can''t find ext3 filesystem on dev dm-1. > [ 4949.197596] EXT2-fs (dm-1): error: can''t find an ext2 filesystem on dev dm-1. > [ 4949.241721] EXT4-fs (dm-1): VFS: Can''t find ext4 filesystemThese printks indicate that the encryption or password is not the same as used when creating the device. So at this stage, this has nothing to do with btrfs.> In my experience btrfs + encryption eats the data, this is not the > first time I had this problem with btrfs so I am considering switching > to ext4, but can I still get the other data back on the broken btrfs??Don''t worry, btrfs doesn''t need encryption to eat your data. If you use it, keep backups. Good luck with getting back the data ! -- cJ -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> These printks indicate that the encryption or password is not the same as used when creating the device. > So at this stage, this has nothing to do with btrfs.No, Ive decrypted the volume with the password, I can confirm it and also I haven''t change it, BTW I have some new output from the kernel when trying to mount it: [21754.913248] usb 2-1.1: new high speed USB device number 20 using ehci_hcd [21755.119495] scsi45 : usb-storage 2-1.1:1.0 [21757.616505] scsi 45:0:0:0: Direct-Access WDC WD75 00BPVT-22HXZT1 01.0 PQ: 0 ANSI: 5 [21757.633275] sd 45:0:0:0: Attached scsi generic sg4 type 0 [21757.634765] sd 45:0:0:0: [sdc] 1465149168 512-byte logical blocks: (750 GB/698 GiB) [21757.635789] sd 45:0:0:0: [sdc] Write Protect is off [21757.635798] sd 45:0:0:0: [sdc] Mode Sense: 43 00 00 00 [21757.637434] sd 45:0:0:0: [sdc] Write cache: disabled, read cache: enabled, doesn''t support DPO or FUA [21757.727481] sdc: sdc1 [21757.730497] sd 45:0:0:0: [sdc] Attached SCSI disk [21757.737422] sd 45:0:0:0: [sdc] Sense Key : Recovered Error [current] [descriptor] [21757.737438] Descriptor sense data with sense descriptors (in hex): [21757.737443] 72 01 04 1d 00 00 00 0e 09 0c 00 00 00 00 57 00 [21757.737462] 00 00 00 00 00 50 [21757.737472] sd 45:0:0:0: [sdc] ASC=0x4 ASCQ=0x1d [21757.868565] sd 45:0:0:0: [sdc] Sense Key : Recovered Error [current] [descriptor] [21757.868580] Descriptor sense data with sense descriptors (in hex): [21757.868585] 72 01 04 1d 00 00 00 0e 09 0c 00 00 00 00 00 00 [21757.868604] 00 00 00 00 00 50 [21757.868614] sd 45:0:0:0: [sdc] ASC=0x4 ASCQ=0x1d [21777.246960] EXT3-fs (dm-1): error: can''t find ext3 filesystem on dev dm-1. [21777.283216] EXT2-fs (dm-1): error: can''t find an ext2 filesystem on dev dm-1. [21777.338992] EXT4-fs (dm-1): VFS: Can''t find ext4 filesystem [21777.456509] REISERFS warning (device dm-1): sh-2021 reiserfs_fill_super: can not find reiserfs on dm-1 [21777.503417] XFS (dm-1): bad magic number [21777.503428] XFS (dm-1): SB validate failed [21777.622915] FAT-fs (dm-1): bogus number of reserved sectors [21777.622926] FAT-fs (dm-1): Can''t find a valid FAT filesystem [21777.663109] FAT-fs (dm-1): bogus number of reserved sectors [21777.663120] FAT-fs (dm-1): Can''t find a valid FAT filesystem [21788.328298] sd 45:0:0:0: [sdc] Sense Key : Recovered Error [current] [descriptor] [21788.328312] Descriptor sense data with sense descriptors (in hex): [21788.328317] 72 01 04 1d 00 00 00 0e 09 0c 00 00 00 00 00 00 [21788.328335] 00 00 00 00 00 50 [21788.328345] sd 45:0:0:0: [sdc] ASC=0x4 ASCQ=0x1d [21788.342307] sd 45:0:0:0: [sdc] Sense Key : Recovered Error [current] [descriptor] [21788.342323] Descriptor sense data with sense descriptors (in hex): [21788.342329] 72 01 04 1d 00 00 00 0e 09 0c 00 00 00 00 00 00 [21788.342353] 00 4f 00 c2 00 50 [21788.342366] sd 45:0:0:0: [sdc] ASC=0x4 ASCQ=0x1d [21788.354571] sd 45:0:0:0: [sdc] Sense Key : Recovered Error [current] [descriptor] [21788.354587] Descriptor sense data with sense descriptors (in hex): [21788.354592] 72 01 04 1d 00 00 00 0e 09 0c 00 00 00 00 00 00 [21788.354611] 00 00 00 00 00 50 [21788.354620] sd 45:0:0:0: [sdc] ASC=0x4 ASCQ=0x1d [21790.015454] sd 45:0:0:0: [sdc] Sense Key : Recovered Error [current] [descriptor] [21790.015469] Descriptor sense data with sense descriptors (in hex): [21790.015473] 72 01 04 1d 00 00 00 0e 09 0c 00 00 00 00 00 00 [21790.015492] 00 4f 00 c2 00 50 [21790.015502] sd 45:0:0:0: [sdc] ASC=0x4 ASCQ=0x1d [21828.295120] ecryptfs_encrypt_page: Error attempting to write lower page; rc = [-5] [21828.295128] ecryptfs_writepage: Error encrypting page (upper index [0x0000000000000009]) [21828.295186] ecryptfs_encrypt_page: Error attempting to write lower page; rc = [-5] [21828.295190] ecryptfs_writepage: Error encrypting page (upper index [0x0000000000000009]) [21828.295246] ecryptfs_encrypt_page: Error attempting to write lower page; rc = [-5] [21828.295250] ecryptfs_writepage: Error encrypting page (upper index [0x0000000000000009]) -- Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 24 Nov 2011 21:43:50 +0000 810d4rk <810d4rk@gmail.com> wrote:> > These printks indicate that the encryption or password is not the same as used when creating the device. > > So at this stage, this has nothing to do with btrfs. > > No, Ive decrypted the volume with the password, I can confirm it and > also I haven''t change it, BTW I have some new output from the kernel > when trying to mount it: > > [21754.913248] usb 2-1.1: new high speed USB device number 20 using ehci_hcd > [21755.119495] scsi45 : usb-storage 2-1.1:1.0 > [21757.616505] scsi 45:0:0:0: Direct-Access WDC WD75 > 00BPVT-22HXZT1 01.0 PQ: 0 ANSI: 5 > [21757.633275] sd 45:0:0:0: Attached scsi generic sg4 type 0 > [21757.634765] sd 45:0:0:0: [sdc] 1465149168 512-byte logical blocks: > (750 GB/698 GiB) > [21757.635789] sd 45:0:0:0: [sdc] Write Protect is off > [21757.635798] sd 45:0:0:0: [sdc] Mode Sense: 43 00 00 00 > [21757.637434] sd 45:0:0:0: [sdc] Write cache: disabled, read cache: > enabled, doesn''t support DPO or FUA > [21757.727481] sdc: sdc1 > [21757.730497] sd 45:0:0:0: [sdc] Attached SCSI disk > [21757.737422] sd 45:0:0:0: [sdc] Sense Key : Recovered Error > [current] [descriptor] > [21757.737438] Descriptor sense data with sense descriptors (in hex): > [21757.737443] 72 01 04 1d 00 00 00 0e 09 0c 00 00 00 00 57 00 > [21757.737462] 00 00 00 00 00 50 > [21757.737472] sd 45:0:0:0: [sdc] ASC=0x4 ASCQ=0x1d > [21757.868565] sd 45:0:0:0: [sdc] Sense Key : Recovered Error > [current] [descriptor] > [21757.868580] Descriptor sense data with sense descriptors (in hex): > [21757.868585] 72 01 04 1d 00 00 00 0e 09 0c 00 00 00 00 00 00 > [21757.868604] 00 00 00 00 00 50 > [21757.868614] sd 45:0:0:0: [sdc] ASC=0x4 ASCQ=0x1d > [21777.246960] EXT3-fs (dm-1): error: can''t find ext3 filesystem on dev dm-1. > [21777.283216] EXT2-fs (dm-1): error: can''t find an ext2 filesystem on dev dm-1. > [21777.338992] EXT4-fs (dm-1): VFS: Can''t find ext4 filesystem > [21777.456509] REISERFS warning (device dm-1): sh-2021 > reiserfs_fill_super: can not find reiserfs on dm-1 > [21777.503417] XFS (dm-1): bad magic number > [21777.503428] XFS (dm-1): SB validate failed > [21777.622915] FAT-fs (dm-1): bogus number of reserved sectors > [21777.622926] FAT-fs (dm-1): Can''t find a valid FAT filesystem > [21777.663109] FAT-fs (dm-1): bogus number of reserved sectors > [21777.663120] FAT-fs (dm-1): Can''t find a valid FAT filesystemMy mistake, the same printks are printed when the encryption key is incorrect, I''ve seen that here. It looks like you have some ugly hardware errors. The kernel cannot read from the drive, so it cannot guess the file system on it. If the data is valuable, you could try to ddrescue the drive to a bigger one. (>750GB... and that will take time...) and attempt to mount the rescued data. If the drive is in an USB enclosure, you could plug it directly via SATA to the system (maybe it has issues?). ++ -- cJ -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> My mistake, the same printks are printed when the encryption key is incorrect, I''ve seen that here. > It looks like you have some ugly hardware errors. > The kernel cannot read from the drive, so it cannot guess the file system on it. > If the data is valuable, you could try to ddrescue the drive to a bigger one. > (>750GB... and that will take time...) and attempt to mount the rescued data. > If the drive is in an USB enclosure, you could plug it directly via SATA to the system (maybe it has issues?).The hard drive is brand new, I also plugged it directly via eSATA and checked the SMART data and run some tests and it succeeded in all, if I format the drive again I have a working file-system for sure but some of my data that is not on the backup disk will be gone.. I had some time ago on opensuse tumbleweed a encrypted btrfs system and it was gone some time ago like this external hard drive, I also had various btrfs hard drives without encryption and they never failed, and I will make a image of the disk but that will be later because I don''t have a backup hard drive bigger than 750gb, maybe btrfs fsck can restore my disk when it is officially released? -- Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Is anyone able to reproduce the problems that I described? I can help if anyone is interested.> The hard drive is brand new, I also plugged it directly via eSATA and > checked the SMART data and run some tests and it succeeded in all, if > I format the drive again I have a working file-system for sure but > some of my data that is not on the backup disk will be gone.. I had > some time ago on opensuse tumbleweed a encrypted btrfs system and it > was gone some time ago like this external hard drive, I also had > various btrfs hard drives without encryption and they never failed,-- Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Nov 25, 2011 at 10:40:00AM +0000, 810d4rk wrote:> > My mistake, the same printks are printed when the encryption key is incorrect, I''ve seen that here. > > It looks like you have some ugly hardware errors. > > The kernel cannot read from the drive, so it cannot guess the file system on it. > > If the data is valuable, you could try to ddrescue the drive to a bigger one. > > (>750GB... and that will take time...) and attempt to mount the rescued data. > > If the drive is in an USB enclosure, you could plug it directly via SATA to the system (maybe it has issues?). > > The hard drive is brand new, I also plugged it directly via eSATA and > checked the SMART data and run some tests and it succeeded in all, if > I format the drive again I have a working file-system for sure but > some of my data that is not on the backup disk will be gone.. I had > some time ago on opensuse tumbleweed a encrypted btrfs system and it > was gone some time ago like this external hard drive, I also had > various btrfs hard drives without encryption and they never failed, > and I will make a image of the disk but that will be later because I > don''t have a backup hard drive bigger than 750gb, maybe btrfs fsck can > restore my disk when it is officially released?If you plug it in directly with esata, do the IO errors go away? If so, please post the kernel messages from that. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
I plugged it directly by sata and this is what I get from the 3.1 kernel:
[ 577.850429] ata3: exception Emask 0x10 SAct 0x0 SErr 0x4050000
action 0xe frozen
[ 577.850433] ata3: irq_stat 0x00000040, connection status changed
[ 577.850436] ata3: SError: { PHYRdyChg CommWake DevExch }
[ 577.850443] ata3: hard resetting link
[ 581.768015] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 581.829148] ata3.00: ATA-8: WDC WD7500BPVT-22HXZT1, 01.01A01, max UDMA/133
[ 581.829151] ata3.00: 1465149168 sectors, multi 0: LBA48 NCQ (depth 31/32), AA
[ 581.833146] ata3.00: configured for UDMA/133
[ 581.848043] ata3: EH complete
[ 581.848134] scsi 2:0:0:0: Direct-Access ATA WDC
WD7500BPVT-2 01.0 PQ: 0 ANSI: 5
[ 581.848250] sd 2:0:0:0: [sdb] 1465149168 512-byte logical blocks:
(750 GB/698 GiB)
[ 581.848253] sd 2:0:0:0: [sdb] 4096-byte physical blocks
[ 581.848300] sd 2:0:0:0: [sdb] Write Protect is off
[ 581.848302] sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[ 581.848323] sd 2:0:0:0: [sdb] Write cache: enabled, read cache:
enabled, doesn''t support DPO or FUA
[ 581.921417] sdb: sdb1
[ 581.921642] sd 2:0:0:0: [sdb] Attached SCSI disk
[ 660.040263] EXT4-fs (dm-4): VFS: Can''t find ext4 filesystem
> If you plug it in directly with esata, do the IO errors go away? If so,
> please post the kernel messages from that.
>
> -chris
--
Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
What can be done about this? Is there anyone able to reproduce the problem? On 30/11/2011, 810d4rk <810d4rk@gmail.com> wrote:> I plugged it directly by sata and this is what I get from the 3.1 kernel: > > [ 577.850429] ata3: exception Emask 0x10 SAct 0x0 SErr 0x4050000 > action 0xe frozen > [ 577.850433] ata3: irq_stat 0x00000040, connection status changed > [ 577.850436] ata3: SError: { PHYRdyChg CommWake DevExch } > [ 577.850443] ata3: hard resetting link > [ 581.768015] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) > [ 581.829148] ata3.00: ATA-8: WDC WD7500BPVT-22HXZT1, 01.01A01, max > UDMA/133 > [ 581.829151] ata3.00: 1465149168 sectors, multi 0: LBA48 NCQ (depth > 31/32), AA > [ 581.833146] ata3.00: configured for UDMA/133 > [ 581.848043] ata3: EH complete > [ 581.848134] scsi 2:0:0:0: Direct-Access ATA WDC > WD7500BPVT-2 01.0 PQ: 0 ANSI: 5 > [ 581.848250] sd 2:0:0:0: [sdb] 1465149168 512-byte logical blocks: > (750 GB/698 GiB) > [ 581.848253] sd 2:0:0:0: [sdb] 4096-byte physical blocks > [ 581.848300] sd 2:0:0:0: [sdb] Write Protect is off > [ 581.848302] sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00 > [ 581.848323] sd 2:0:0:0: [sdb] Write cache: enabled, read cache: > enabled, doesn''t support DPO or FUA > [ 581.921417] sdb: sdb1 > [ 581.921642] sd 2:0:0:0: [sdb] Attached SCSI disk > [ 660.040263] EXT4-fs (dm-4): VFS: Can''t find ext4 filesystem > >> If you plug it in directly with esata, do the IO errors go away? If so, >> please post the kernel messages from that. >> >> -chris-- Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Dec 1, 2011 at 5:15 AM, 810d4rk <810d4rk@gmail.com> wrote:> I plugged it directly by sata and this is what I get from the 3.1 kernel:> [ 581.921417] sdb: sdb1 > [ 581.921642] sd 2:0:0:0: [sdb] Attached SCSI disk > [ 660.040263] EXT4-fs (dm-4): VFS: Can''t find ext4 filesystem... and then what? Did you try decrypting and mounting it? -- Fajar -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
The disk is decrypted, after that I try to mount and it doesn''t mount, this last message appears on the log after trying to mount the btrfs disk:> [ 660.040263] EXT4-fs (dm-4): VFS: Can''t find ext4 filesystemOn 13/12/2011, Fajar A. Nugraha <list@fajar.net> wrote:> On Thu, Dec 1, 2011 at 5:15 AM, 810d4rk <810d4rk@gmail.com> wrote: >> I plugged it directly by sata and this is what I get from the 3.1 kernel: > >> [ 581.921417] sdb: sdb1 >> [ 581.921642] sd 2:0:0:0: [sdb] Attached SCSI disk >> [ 660.040263] EXT4-fs (dm-4): VFS: Can''t find ext4 filesystem > > ... and then what? Did you try decrypting and mounting it? > > -- > Fajar >-- Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Is anyone there trying to reproduce the bug?? -- Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Dec 15, 2011 at 1:44 PM, 810d4rk <810d4rk@gmail.com> wrote:> Is anyone there trying to reproduce the bug?? >I''ve been using btrfs and luks encryption on my Acer netbook for about a year now. I haven''t had an unmountable corruption on that computer yet. What are your goals now? Are you trying to recover data from this disk, or are you trying to accomplish some debugging? Reviewing the thread, I don''t see where you''ve run btrfsck on the /dev/mapper/<entry>. Although btrfsck won''t fix anything, it might give some insight as the the extent of the corruption. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> I''ve been using btrfs and luks encryption on my Acer netbook for about > a year now. I haven''t had an unmountable corruption on that computer > yet. > > What are your goals now?I would like to recover the data that is not in the backup.> Are you trying to recover data from this disk, or are you trying to > accomplish some debugging?I am trying to recover the data, also I think this bug needs to be fixed.> Reviewing the thread, I don''t see where you''ve run btrfsck on the > /dev/mapper/<entry>. > > Although btrfsck won''t fix anything, it might give some insight as the > the extent of the corruption.I have run it now and it says "No valid Btrfs found" -- Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
I''m not having luck getting the encrypted btrfs back since the drive the drive was unplugged during a write operation, the experimental fsck with the repair option gives no valid btrfs found, mount gives this: sudo mount -t btrfs /dev/dm-1 /media/ mount: wrong fs type, bad option, bad superblock on /dev/mapper/udisks-luks-uuid-269300fe-1329-42f8-b7fa-4a399a71d56f-uid1000, missing codepage or helper program, or other error There is nothing more to do to this? On 23 December 2011 14:25, 810d4rk <810d4rk@gmail.com> wrote:>> I''ve been using btrfs and luks encryption on my Acer netbook for about >> a year now. I haven''t had an unmountable corruption on that computer >> yet. >> >> What are your goals now? > > I would like to recover the data that is not in the backup. > >> Are you trying to recover data from this disk, or are you trying to >> accomplish some debugging? > > I am trying to recover the data, also I think this bug needs to be fixed. > >> Reviewing the thread, I don''t see where you''ve run btrfsck on the >> /dev/mapper/<entry>. >> >> Although btrfsck won''t fix anything, it might give some insight as the >> the extent of the corruption. > > I have run it now and it says "No valid Btrfs found" > > > -- > Thanks-- Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html