# 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 ***************Last edited by mjbjr on Tue May 26, 2015 12:17 am; edited 1 time in total

----------

## 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

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

to stop the polling. You can check with

```
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,

```
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:

```
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

 *Logicien wrote:*   

> 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
> 
> ```
> ...

 

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

 *Logicien wrote:*   

> 
> 
> 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.

 *Logicien wrote:*   

> 
> 
> 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.

 *Logicien wrote:*   

> 
> 
> 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

 *Logicien wrote:*   

> 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

 *NeddySeagoon wrote:*   

> mjbjr,
> 
> ```
> 2) use gparted to
> 
> ...

 

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.

 :Wink: 

----------

