harddrive won't "settle" after mount [SOLVED]

[mjbjr]

I have a new harddrive that won't "settle" (drive light and hw monitor show it continuously being used even though no programs or commands are using it) after mounting it.
This is a HGST 4TB drive and the only difference beween it and another HGST 4TB drive (same model) that doesn't exhibit this problem is that the drive in question was wiped with 'dd' first.
Both of these drives are not boot drives, just data drives.

The procedure I used for this new out of the box drive is:

1) wipe with dd (dd if=/dev/zero of=/dev/sdb bs=1M)
2) use gparted to
create gpt partition table
create whole drive ext4 partition
3) check drive info with parted
4) create udev rule
5) mount drive

whether I mount the drive with the udev rule or manually makes no difference in regards to the problem, it happens in both cases.

immediately upon unmounting the drive all access of the drive stops, of course. Upon remounting, the access problem immediately restarts and continues endlessly.
It has gone on for twenty minutes before I stopped the problem by unmounting it.

Later, just in case it was some sort of gparted filesystem problem I also did a 'mkfs.ext4 -L "gpt" /dev/sdb1' on the drive, but that didn't solve anything. The problem persists.

Also, I was able to edit and save a test text file to the mounted partition without problems.

I've searched around the net, but haven't seen anything that would suggest a problem with my procedure.

This is not a raid setup and I'm aware of that recent ext4/raid problem with later kernels.

localhost ~ # uname -a
Linux localhost 3.16.5-gentoo #3 SMP Wed Nov 26 03:54:40 PST 2014 x86_64 Intel(R) Core(TM) i7-4820K CPU @ 3.70GHz GenuineIntel GNU/Linux

I'm using udev-216

It would be great if someone could tell me the error(s) of my ways.

thanks.

prcedure details follow:

*****************************************

localhost ~ # dd if=/dev/zero of=/dev/sdb bs=1M
dd: error writing '/dev/sdb': No space left on device
3815448+0 records in
3815447+0 records out
4000787030016 bytes (4.0 TB) copied, 30375 s, 132 MB/s

use gparted to
create gpt partition table
create whole drive ext4 partition

localhost ~ # gparted /dev/sdb
======================
libparted : 3.2
======================
/dev/sdb: unrecognised disk label
/dev/sdb: unrecognised disk label


check with parted

localhost ~ # parted /dev/sdb
GNU Parted 3.2
Using /dev/sdb

(parted) print
Model: ATA HGST HDN724040AL (scsi)
Disk /dev/sdb: 4001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number Start End Size File system Name Flags
1 1049kB 4001GB 4001GB ext4

(for the usev rule)

localhost ~ # udevadm info -q all -n /dev/sdb1
P: /devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sdb/sdb1
N: sdb1
S: disk/by-id/ata-HGST_HDN724040ALE640_PK2338P4HGDRRC-part1
S: disk/by-id/wwn-0x5000cca249d4a47f-part1
S: disk/by-partuuid/64e390ba-d49d-4eec-a406-73c1e24c95fd
S: disk/by-uuid/a7654ed5-8f11-49a8-b8c8-141f4df5486f
E: DEVLINKS=/dev/disk/by-id/ata-HGST_HDN724040ALE640_PK2338P4HGDRRC-part1 /dev/disk/by-id/wwn-0x5000cca249d4a47f-part1 /dev/disk/by-partuuid/64e390ba-d49d-4eec-a406-73c1e24c95fd /dev/disk/by-uuid/a7654ed5-8f11-49a8-b8c8-141f4df5486f
E: DEVNAME=/dev/sdb1
E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sdb/sdb1
E: DEVTYPE=partition
E: ID_ATA=1
E: ID_ATA_DOWNLOAD_MICROCODE=1
E: ID_ATA_FEATURE_SET_APM=1
E: ID_ATA_FEATURE_SET_APM_ENABLED=0
E: ID_ATA_FEATURE_SET_HPA=1
E: ID_ATA_FEATURE_SET_HPA_ENABLED=1
E: ID_ATA_FEATURE_SET_PM=1
E: ID_ATA_FEATURE_SET_PM_ENABLED=1
E: ID_ATA_FEATURE_SET_PUIS=1
E: ID_ATA_FEATURE_SET_PUIS_ENABLED=0
E: ID_ATA_FEATURE_SET_SECURITY=1
E: ID_ATA_FEATURE_SET_SECURITY_ENABLED=0
E: ID_ATA_FEATURE_SET_SECURITY_ERASE_UNIT_MIN=510
E: ID_ATA_FEATURE_SET_SECURITY_FROZEN=1
E: ID_ATA_FEATURE_SET_SMART=1
E: ID_ATA_FEATURE_SET_SMART_ENABLED=1
E: ID_ATA_ROTATION_RATE_RPM=7200
E: ID_ATA_SATA=1
E: ID_ATA_SATA_SIGNAL_RATE_GEN1=1
E: ID_ATA_SATA_SIGNAL_RATE_GEN2=1
E: ID_ATA_WRITE_CACHE=1
E: ID_ATA_WRITE_CACHE_ENABLED=1
E: ID_BUS=ata
E: ID_FS_TYPE=ext4
E: ID_FS_USAGE=filesystem
E: ID_FS_UUID=a7654ed5-8f11-49a8-b8c8-141f4df5486f
E: ID_FS_UUID_ENC=a7654ed5-8f11-49a8-b8c8-141f4df5486f
E: ID_FS_VERSION=1.0
E: ID_MODEL=HGST_HDN724040ALE640
E: ID_MODEL_ENC=HGST\x20HDN724040ALE640\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20
E: ID_PART_ENTRY_DISK=8:16
E: ID_PART_ENTRY_NUMBER=1
E: ID_PART_ENTRY_OFFSET=2048
E: ID_PART_ENTRY_SCHEME=gpt
E: ID_PART_ENTRY_SIZE=7814033408
E: ID_PART_ENTRY_TYPE=0fc63daf-8483-4772-8e79-3d69d8477de4
E: ID_PART_ENTRY_UUID=64e390ba-d49d-4eec-a406-73c1e24c95fd
E: ID_PART_TABLE_TYPE=gpt
E: ID_PART_TABLE_UUID=7dabd764-1b84-434e-9a98-42d9cb68849c
E: ID_REVISION=MJAOA5E0
E: ID_SERIAL=HGST_HDN724040ALE640_PK2338P4HGDRRC
E: ID_SERIAL_SHORT=PK2338P4HGDRRC
E: ID_TYPE=disk
E: ID_WWN=0x5000cca249d4a47f
E: ID_WWN_WITH_EXTENSION=0x5000cca249d4a47f
E: MAJOR=8
E: MINOR=17
E: SUBSYSTEM=block
E: USEC_INITIALIZED=763008752


localhost ~ # /lib/udev/scsi_id --whitelisted --page=0x80 --device=/dev/sdb1
SATA HGST HDN724040AL PK2338P4HGDRRC


udev rule
# venus
# works - creates lrwxrwxrwx 1 root root 4 May 23 02:47 venus1 -> sdb1
# does not create plain venus sdb device
KERNEL=="sd?1", SUBSYSTEM=="block", PROGRAM="/lib/udev/scsi_id --page=0x80 --whitelisted --device=/dev/%k", RESULT=="SATA HGST HDN724040AL PK2338P4HGDRRC", SYMLINK+="venus%n", MODE="0774"

mount it
localhost ~ # mount -t auto /dev/venus1 /mnt/venus1

after mounting
'mount' shows

/dev/sdb1 on /mnt/venus1 type ext4 (rw)


do this to see if it fixes drive not settling issue, it doesn't

localhost ~ # mkfs.ext4 -L "gpt" /dev/sdb1
mke2fs 1.42.10 (18-May-2014)
/dev/sdb1 contains a ext4 file system
last mounted on /mnt/venus1 on Sun May 24 02:08:29 2015
Proceed anyway? (y,n) y
Creating filesystem with 976754176 4k blocks and 244195328 inodes
Filesystem UUID: cfb26440-74a6-4596-9e2b-47cdda24a839
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848, 512000000, 550731776, 644972544

Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done


********* end of details ***************

[Logicien]

Hello,

I don't think it' enough to explain your problem, but Udev have a rule file /lib/udev/rules.d/60-persistent-storage.rules who consist to poll a drive, removal drive and cdrom. It is annoying, so I create a rule /etc/udev/rules.d/99-device-polling.rules

Code: Select all

SUBSYSTEM=="block", ENV{ID_VENDOR}=="*", ENV{ID_MODEL}=="*", ENV{UDISKS_DISABLE_POLLING}="1"

to stop the polling. You can check with

Code: Select all

ps aux | grep -i poll

if the polling is active. An other process can also be the culprit for example, a desktop feature.

In your BIOS configuration is there something who can trigger this light on behavior? It would be very curious if the light stay on because of a partition table and a format procedure. What about using Gdisk and another filesystem?

When using dd, was there some warnings about bad sectors where it could not write zeros? What about if you remove your Udev rule file?

[NeddySeagoon]

mjbjr,

Code: Select all

2) use gparted to
create gpt partition table
create whole drive ext4 partition 

It may be the ext4 driver completing making the ext4 filesystem. On big (I don't know what big is) ext4 only creates enough of the filesystem for you to use.
The rest is created in the background. Rather like UDF on a DVD+RW.

[krinn]

It might have done nothing to dd with zero your disk, because nearly all disks don't use 0 as "empty" entry (because 0 is a too common value, they use a higher range like from 0xf0 to 0xff), and many firmware are able to handle 0 cleaning request and will actually do nothing (many software and fs also handle that by clearing only the fat area instead of doing what you think it should do). If it has really do it, you would have stay a long time waiting it to end the request (so if it has done it quick, be happy it have a nice firmware that stop you doing shit with it).
Filling a drive is not really something anyone should do, if you want fill a drive, fill it with random values, if you don't have any need to have random values in the drive, then you have no need to fill it at all. As now drives have many platers and as i don't think any manufacturers care anymore to build the sector geometry depending on the disk rotation speed, it might even be a real pain for the drive doing that.



I would do a bit like logicien, but differently.
- no udev rule at all: you can do what you wish with mount /dev/disk/by-label/gpt /mnt/venus1 without the need to add another rule to target it.
You can also use them if you prefer:

Code: Select all

S: disk/by-id/wwn-0x5000cca249d4a47f-part1
S: disk/by-partuuid/64e390ba-d49d-4eec-a406-73c1e24c95fd
S: disk/by-uuid/a7654ed5-8f11-49a8-b8c8-141f4df5486f 

- As it might (should) be udev, just confirm it, stop udev and see if it stop doing that (yes, you can really live with an udev that is stopped, no discovery of device until you restart it)

[mjbjr]

Hello,

I don't think it' enough to explain your problem, but Udev have a rule file /lib/udev/rules.d/60-persistent-storage.rules who consist to poll a drive, removal drive and cdrom. It is annoying, so I create a rule /etc/udev/rules.d/99-device-polling.rules

Code: Select all

SUBSYSTEM=="block", ENV{ID_VENDOR}=="*", ENV{ID_MODEL}=="*", ENV{UDISKS_DISABLE_POLLING}="1"

to stop the polling. You can check with

Code: Select all

ps aux | grep -i poll

if the polling is active. An other process can also be the culprit for example, a desktop feature.

I didn't know about polling, thanks, but apparently that's not happening:

localhost ~ # ps aux | grep -i poll
root 28547 0.0 0.0 8980 780 pts/2 S+ 11:12 0:00 grep --colour=auto -i poll

In your BIOS configuration is there something who can trigger this light on behavior?

No changes have been made in the BIOS. If this drive isn't mounted there's no problem and there's another exact same drive that wasn't wiped that doesn't have this "polling" problem.

It would be very curious if the light stay on because of a partition table and a format procedure. What about using Gdisk and another filesystem?

I've checked on things using both fdisk and gdisk, but haven't noticed any anomalies when using them to check on what's been done. The next thing will be to try different partitioning and fs types.

When using dd, was there some warnings about bad sectors where it could not write zeros?

No warnings other than the out of space one:

localhost ~ # dd if=/dev/zero of=/dev/sdb bs=512
dd: error writing '/dev/sdb': No space left on device
7814037169+0 records in
7814037168+0 records out
4000787030016 bytes (4.0 TB) copied, 76336.3 s, 52.4 MB/s

What about if you remove your Udev rule file?

I can totally avoid the udev rule by mounting manually... same result either way.


Thanks for your reply

[mjbjr]

mjbjr,

Code: Select all

2) use gparted to
create gpt partition table
create whole drive ext4 partition 

It may be the ext4 driver completing making the ext4 filesystem. On big (I don't know what big is) ext4 only creates enough of the filesystem for you to use.
The rest is created in the background. Rather like UDF on a DVD+RW.

Bingo!! Give that man a cigar, he just missed a gold watch and chain.

While I had considered somthing like this and had let this initialization go on a number of times, 5, 10, 20, and 40 minutes, I couldn't remember ever having seen this.

Googling around someone mentioned 'iotop', which I then used to see 'ext4lazyinit' at the top of the stack burning away.

From https://www.thomas-krenn.com/en/wiki/Ext4_Filesystem...

"Lazy Initialization
When creating an Ext4 file system, the existing regions of the inode tables must be cleaned (overwritten with nulls, or "zeroed"). The "lazyinit" feature should significantly accelerate the creation of a file system, because it does not immediately initialize all inode tables, initializing them gradually instead during the initial mounting process in background (from Kernel version 2.6.37).[18][19] Regarding this see the extracts from the mkfs.ext4 man pages:[20]

If enabled and the uninit_bg feature is enabled, the inode table will not be fully initialized by mke2fs. This speeds up file system initialization noticeably, but it requires the kernel to finish initializing the file system in the background when the file system is first mounted. If the option value is omitted, it defaults to 1 to enable lazy inode table zeroing.
One should be careful when testing the performance of a freshly created file system. The "lazy initialization" feature may write a lot of information to the hard disk after the initial mounting and thereby invalidate the test results. At first, the "ext4lazyinit" kernel process writes at up to 16,000kB/s to the device and thereby uses a great deal of the hard disk’s bandwidth (see also I/O Statistics by Process). In order to prevent lazy initialization, advanced options are offered by the mkfs.ext4 command:[20]

mkfs.ext4 -E lazy_itable_init=0,lazy_journal_init=0 /dev/mapper/fc-root

By specifying these options, the inodes and the journal will be initialized immediately during creation."

I don't know how long it took to do 4TB because I started it and went out to run a few arrands and grab a quick bite.
I was gone for about 90 minutes, and when I got back it had finished.

Thanks Neddy for stirring the pot.

- Martin -

[Logicien]

Just a word to say that I agree with you mjbjr. Solutions are often hidden. NeddySeagoon show us his hidden knowledge and if he like two cigars, I give one too to him.