I have a brand new 2T external Samsung SSD disk. (two of them) for backup.
I tried the first one and had an issue, I tried the second one and got the same issue.
Am I doing something wrong ? I find it hard to believe the SSD (both) are bad.
I plugged in the USB 3.1 adapter, I fdisk /dev/sdd, n, p, default, default, w. then mkfs.ext4 -j /dev/sdd1, then just mount and rsync.
[ 1085.193710] [<ffffffffa94dca7e>] ? account_entity_dequeue+0xae/0xd0 [ 1085.193715] [<ffffffffa9b67c49>] schedule+0x29/0x70 [ 1085.193719] [<ffffffffa9b65721>] schedule_timeout+0x221/0x2d0 [ 1085.193724] [<ffffffffa942a621>] ? __switch_to+0x151/0x580 [ 1085.193730] [<ffffffffa9501052>] ? ktime_get_ts64+0x52/0xf0 [ 1085.193735] [<ffffffffa9b672ed>] io_schedule_timeout+0xad/0x130 [ 1085.193740] [<ffffffffa94c2886>] ? prepare_to_wait_exclusive+0x56/0x90 [ 1085.193744] [<ffffffffa9b67388>] io_schedule+0x18/0x20 [ 1085.193750] [<ffffffffa9743de3>] get_request+0x243/0x7d0 [ 1085.193756] [<ffffffffa977c401>] ? __radix_tree_create+0x11/0x360 [ 1085.193761] [<ffffffffa94c2d00>] ? wake_up_atomic_t+0x30/0x30 [ 1085.193767] [<ffffffffa9746cae>] blk_queue_bio+0xfe/0x400 [ 1085.193772] [<ffffffffa9744ef7>] generic_make_request+0x147/0x380 [ 1085.193778] [<ffffffffa97451a0>] submit_bio+0x70/0x150 [ 1085.193786] [<ffffffffa967e555>] ? bio_alloc_bioset+0x115/0x310 [ 1085.193791] [<ffffffffa967a197>] _submit_bh+0x127/0x160 [ 1085.193797] [<ffffffffa967a1e0>] submit_bh+0x10/0x20 [ 1085.193808] [<ffffffffc1bd8424>] ext4_read_block_bitmap_nowait+0x4c4/0x640 [ext4] [ 1085.193828] [<ffffffffc1c16641>] ext4_mb_init_cache+0x181/0x6e0 [ext4] [ 1085.193834] [<ffffffffa95c5afe>] ? lru_cache_add+0xe/0x10 [ 1085.193840] [<ffffffffa95b74de>] ? find_or_create_page+0x5e/0xa0 [ 1085.193858] [<ffffffffc1c16cc6>] ext4_mb_init_group+0x126/0x230 [ext4] [ 1085.193874] [<ffffffffc1c16f54>] ext4_mb_good_group+0x184/0x1a0 [ext4] [ 1085.193889] [<ffffffffc1c19735>] ext4_mb_regular_allocator+0x1c5/0x470 [ext4] [ 1085.193906] [<ffffffffc1c12d0c>] ? __ext4_journal_stop+0x3c/0xb0 [ext4] [ 1085.193921] [<ffffffffc1c14bec>] ? ext4_mb_normalize_request+0x20c/0x560 [ext4] [ 1085.193936] [<ffffffffc1c1b59b>] ext4_mb_new_blocks+0x65b/0xa20 [ext4] [ 1085.193942] [<ffffffffa967918d>] ? __getblk+0x2d/0x300 [ 1085.193961] [<ffffffffc1c223cb>] ext4_ind_map_blocks+0xb9b/0xc20 [ext4] [ 1085.193968] [<ffffffffa94c6258>] ? hrtimer_cancel+0x28/0x40 [ 1085.193973] [<ffffffffa95d82c8>] ? zone_statistics+0x88/0xa0 [ 1085.193987] [<ffffffffc1bdfd35>] ext4_map_blocks+0x295/0x6e0 [ext4] [ 1085.193993] [<ffffffffa9657c7e>] ? do_select+0x73e/0x7c0 [ 1085.193999] [<ffffffffa961c0b2>] ? kmem_cache_alloc+0x1c2/0x1f0 [ 1085.194006] [<ffffffffa96787b1>] ? alloc_buffer_head+0x21/0x60 [ 1085.194018] [<ffffffffc1be035f>] _ext4_get_block+0x1df/0x220 [ext4] [ 1085.194030] [<ffffffffc1be03b6>] ext4_get_block+0x16/0x20 [ext4] [ 1085.194036] [<ffffffffa967ae78>] __block_write_begin_int+0x198/0x5f0 [ 1085.194041] [<ffffffffa961c0b2>] ? kmem_cache_alloc+0x1c2/0x1f0 [ 1085.194053] [<ffffffffc1be03a0>] ? _ext4_get_block+0x220/0x220 [ext4] [ 1085.194067] [<ffffffffc1be4c56>] ? ext4_write_begin+0x116/0x440 [ext4] [ 1085.194073] [<ffffffffa967b2e1>] __block_write_begin+0x11/0x20 [ 1085.194085] [<ffffffffc1be4ccf>] ext4_write_begin+0x18f/0x440 [ext4] [ 1085.194091] [<ffffffffa95b5f84>] generic_file_buffered_write+0x124/0x2c0 [ 1085.194098] [<ffffffffa95b88c2>] __generic_file_aio_write+0x1e2/0x400 [ 1085.194105] [<ffffffffa95b8b39>] generic_file_aio_write+0x59/0xa0 [ 1085.194116] [<ffffffffc1bda322>] ext4_file_write+0xd2/0x1e0 [ext4] [ 1085.194121] [<ffffffffa9640823>] do_sync_write+0x93/0xe0 [ 1085.194127] [<ffffffffa9641310>] vfs_write+0xc0/0x1f0 [ 1085.194132] [<ffffffffa964212f>] SyS_write+0x7f/0xf0 [ 1085.194138] [<ffffffffa9b74ddb>] system_call_fastpath+0x22/0x27
Thanks,
Jerry
Do you have any "history" with the adapter you connected them to? If not consider it as a possibility as well (from bad experience of total filesystem/partition corruption on two hard drives only to discover it was something on the motherboard).
Leroy Tennison Network Information/Cyber Security Specialist E: leroy@datavoiceint.com 2220 Bush Dr McKinney, Texas 75070 www.datavoiceint.com TThis message has been sent on behalf of a company that is part of the Harris Operating Group of Constellation Software Inc. These companies are listed here . If you prefer not to be contacted by Harris Operating Group please notify us . This message is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is proprietary, privileged or confidential or otherwise legally exempt from disclosure. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately by e-mail and delete all copies of the message.
________________________________________ From: CentOS centos-bounces@centos.org on behalf of Jerry Geis jerry.geis@gmail.com Sent: Wednesday, December 12, 2018 7:49 AM To: CentOS mailing list Subject: [EXTERNAL] [CentOS] CentOS 7.6 external USB dmesg issue
I have a brand new 2T external Samsung SSD disk. (two of them) for backup.
I tried the first one and had an issue, I tried the second one and got the same issue.
Am I doing something wrong ? I find it hard to believe the SSD (both) are bad.
I plugged in the USB 3.1 adapter, I fdisk /dev/sdd, n, p, default, default, w. then mkfs.ext4 -j /dev/sdd1, then just mount and rsync.
[ 1085.193710] [<ffffffffa94dca7e>] ? account_entity_dequeue+0xae/0xd0 [ 1085.193715] [<ffffffffa9b67c49>] schedule+0x29/0x70 [ 1085.193719] [<ffffffffa9b65721>] schedule_timeout+0x221/0x2d0 [ 1085.193724] [<ffffffffa942a621>] ? __switch_to+0x151/0x580 [ 1085.193730] [<ffffffffa9501052>] ? ktime_get_ts64+0x52/0xf0 [ 1085.193735] [<ffffffffa9b672ed>] io_schedule_timeout+0xad/0x130 [ 1085.193740] [<ffffffffa94c2886>] ? prepare_to_wait_exclusive+0x56/0x90 [ 1085.193744] [<ffffffffa9b67388>] io_schedule+0x18/0x20 [ 1085.193750] [<ffffffffa9743de3>] get_request+0x243/0x7d0 [ 1085.193756] [<ffffffffa977c401>] ? __radix_tree_create+0x11/0x360 [ 1085.193761] [<ffffffffa94c2d00>] ? wake_up_atomic_t+0x30/0x30 [ 1085.193767] [<ffffffffa9746cae>] blk_queue_bio+0xfe/0x400 [ 1085.193772] [<ffffffffa9744ef7>] generic_make_request+0x147/0x380 [ 1085.193778] [<ffffffffa97451a0>] submit_bio+0x70/0x150 [ 1085.193786] [<ffffffffa967e555>] ? bio_alloc_bioset+0x115/0x310 [ 1085.193791] [<ffffffffa967a197>] _submit_bh+0x127/0x160 [ 1085.193797] [<ffffffffa967a1e0>] submit_bh+0x10/0x20 [ 1085.193808] [<ffffffffc1bd8424>] ext4_read_block_bitmap_nowait+0x4c4/0x640 [ext4] [ 1085.193828] [<ffffffffc1c16641>] ext4_mb_init_cache+0x181/0x6e0 [ext4] [ 1085.193834] [<ffffffffa95c5afe>] ? lru_cache_add+0xe/0x10 [ 1085.193840] [<ffffffffa95b74de>] ? find_or_create_page+0x5e/0xa0 [ 1085.193858] [<ffffffffc1c16cc6>] ext4_mb_init_group+0x126/0x230 [ext4] [ 1085.193874] [<ffffffffc1c16f54>] ext4_mb_good_group+0x184/0x1a0 [ext4] [ 1085.193889] [<ffffffffc1c19735>] ext4_mb_regular_allocator+0x1c5/0x470 [ext4] [ 1085.193906] [<ffffffffc1c12d0c>] ? __ext4_journal_stop+0x3c/0xb0 [ext4] [ 1085.193921] [<ffffffffc1c14bec>] ? ext4_mb_normalize_request+0x20c/0x560 [ext4] [ 1085.193936] [<ffffffffc1c1b59b>] ext4_mb_new_blocks+0x65b/0xa20 [ext4] [ 1085.193942] [<ffffffffa967918d>] ? __getblk+0x2d/0x300 [ 1085.193961] [<ffffffffc1c223cb>] ext4_ind_map_blocks+0xb9b/0xc20 [ext4] [ 1085.193968] [<ffffffffa94c6258>] ? hrtimer_cancel+0x28/0x40 [ 1085.193973] [<ffffffffa95d82c8>] ? zone_statistics+0x88/0xa0 [ 1085.193987] [<ffffffffc1bdfd35>] ext4_map_blocks+0x295/0x6e0 [ext4] [ 1085.193993] [<ffffffffa9657c7e>] ? do_select+0x73e/0x7c0 [ 1085.193999] [<ffffffffa961c0b2>] ? kmem_cache_alloc+0x1c2/0x1f0 [ 1085.194006] [<ffffffffa96787b1>] ? alloc_buffer_head+0x21/0x60 [ 1085.194018] [<ffffffffc1be035f>] _ext4_get_block+0x1df/0x220 [ext4] [ 1085.194030] [<ffffffffc1be03b6>] ext4_get_block+0x16/0x20 [ext4] [ 1085.194036] [<ffffffffa967ae78>] __block_write_begin_int+0x198/0x5f0 [ 1085.194041] [<ffffffffa961c0b2>] ? kmem_cache_alloc+0x1c2/0x1f0 [ 1085.194053] [<ffffffffc1be03a0>] ? _ext4_get_block+0x220/0x220 [ext4] [ 1085.194067] [<ffffffffc1be4c56>] ? ext4_write_begin+0x116/0x440 [ext4] [ 1085.194073] [<ffffffffa967b2e1>] __block_write_begin+0x11/0x20 [ 1085.194085] [<ffffffffc1be4ccf>] ext4_write_begin+0x18f/0x440 [ext4] [ 1085.194091] [<ffffffffa95b5f84>] generic_file_buffered_write+0x124/0x2c0 [ 1085.194098] [<ffffffffa95b88c2>] __generic_file_aio_write+0x1e2/0x400 [ 1085.194105] [<ffffffffa95b8b39>] generic_file_aio_write+0x59/0xa0 [ 1085.194116] [<ffffffffc1bda322>] ext4_file_write+0xd2/0x1e0 [ext4] [ 1085.194121] [<ffffffffa9640823>] do_sync_write+0x93/0xe0 [ 1085.194127] [<ffffffffa9641310>] vfs_write+0xc0/0x1f0 [ 1085.194132] [<ffffffffa964212f>] SyS_write+0x7f/0xf0 [ 1085.194138] [<ffffffffa9b74ddb>] system_call_fastpath+0x22/0x27
Thanks,
Jerry _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Do you have any "history" with the adapter you connected them to? If not
consider it as a possibility as well
(from bad experience of total filesystem/partition corruption on two hard
drives only to discover it was >something on the motherboard).
Actually yes I used them many times back on C7.5 Both the motherboard and USB adapter. Thanks,
Jerry
On Wed, 12 Dec 2018 at 09:14, Jerry Geis jerry.geis@gmail.com wrote:
Do you have any "history" with the adapter you connected them to? If not
consider it as a possibility as well
(from bad experience of total filesystem/partition corruption on two hard
drives only to discover it was >something on the motherboard).
Actually yes I used them many times back on C7.5 Both the motherboard and USB adapter. Thanks,
What kind of solid state 2 TB drive is this and how is it 'powered'? It is looking like the drives aren't getting completely written to before being removed as the ext4 error is a 'oh wait this drive doesn't have everything I expected too late to give up aaaaaaaaaah' type oops.
What kind of solid state 2 TB drive is this and how is it 'powered'? It is looking like the drives aren't getting completely written to before being removed as the ext4 error is a 'oh wait this drive doesn't have everything I expected too late to give up aaaaaaaaaah' type oops
This is a Samsung 860 EVO 2TB. my connection is a cable that provides both power and data to the device over the USB 3.1 connection.
Jerry
On Wed, 12 Dec 2018 at 11:38, Jerry Geis jerry.geis@gmail.com wrote:
What kind of solid state 2 TB drive is this and how is it 'powered'? It is looking like the drives aren't getting completely written to before being removed as the ext4 error is a 'oh wait this drive doesn't have everything I expected too late to give up aaaaaaaaaah' type oops
This is a Samsung 860 EVO 2TB. my connection is a cable that provides both power and data to the device over the USB 3.1 connection.
OK the place where I have seen this before is when someone is trying to do that. Usually the drive is not getting enough power and will flake out. The only fix was to put them in an external case with a separate power supply. The SSD drives seem to come up a lot. I don't know if it is an amperage issue or something else, but they expect something that the USB3.1 isn't delivering. I would try putting them in a case which does accept external power and see if it works better.
Jerry _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
I'm a tad confused: you said the USB drive was brand new - did you use them with C 7.5, or not? Can you try to do a b/u using whatever drive you used before?
All the equipment I had before... Motherboard, cable etc... the drives are new and this is the behaviour I was seeing...
I am currently running the badblock check - goign slow - 0 errors so far and 40% done. I will use an older 2.0 programmer that has an external supply and try that...
Thanks everyone.
Jerry
Am 12.12.2018 um 14:49 schrieb Jerry Geis jerry.geis@gmail.com:
Am I doing something wrong ? I find it hard to believe the SSD (both) are bad.
I would check the integrity of this storage device:
# Notice: this destroys your data on the device
badblocks -c 10240 -s -w -t random -v /dev/sdxx
-- LF
-
Jerry Geis -
Leon Fauster -
Leroy Tennison -
Stephen John Smoogen