Linux Archive - why would fdisk -l take so long?

Linux Archive (http://www.linux-archive.org/)

- Debian User (http://www.linux-archive.org/debian-user/)

- - why would fdisk -l take so long? (http://www.linux-archive.org/debian-user/708012-why-would-fdisk-l-take-so-long.html)

why would fdisk -l take so long?

$ date; fdisk -l; date
Thu Sep 27 22:48:21 UTC 2012

Disk /dev/sda: 250.1 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders, total 488397168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00052568

Device Boot Start End Blocks Id System
/dev/sda1 63 39086144 19543041 c W95 FAT32 (LBA)
/dev/sda2 39086145 78140159 19527007+ c W95 FAT32 (LBA)
/dev/sda3 78140160 234420479 78140160 83 Linux
/dev/sda4 234420480 488396799 126988160 5 Extended
/dev/sda5 234420543 353429999 59504728+ c W95 FAT32 (LBA)
/dev/sda6 353430063 372981104 9775521 c W95 FAT32 (LBA)
/dev/sda7 372981168 392516144 9767488+ c W95 FAT32 (LBA)
/dev/sda8 392516208 431570159 19526976 83 Linux
/dev/sda9 431570223 441353744 4891761 83 Linux
/dev/sda10 441353808 446253569 2449881 83 Linux
/dev/sda11 446253633 449819999 1783183+ 83 Linux
/dev/sda12 449822720 488396799 19287040 83 Linux
Thu Sep 27 22:48:59 UTC 2012

--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAFakBwhiHFaTiqirsyGz-3XK4qnAC51fMrUttPL6p+CvMLy+5A@mail.gmail.com">http ://lists.debian.org/CAFakBwhiHFaTiqirsyGz-3XK4qnAC51fMrUttPL6p+CvMLy+5A@mail.gmail.com

why would fdisk -l take so long?

On Thursday, September 27, 2012 10:52:26 PM Albretch Mueller wrote:
> $ date; fdisk -l; date
> Thu Sep 27 22:48:21 UTC 2012
> ...
> Thu Sep 27 22:48:59 UTC 2012

Failing boot sector? Some other sector it has to read is failing? Check the
logs. Try (from smartmontools):
smartctl -A /dev/sda | egrep -i "sector|realloc"

--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201209272347.31024.neal.p.murphy@alum.wpi.edu">htt p://lists.debian.org/201209272347.31024.neal.p.murphy@alum.wpi.edu

why would fdisk -l take so long?

Because your disk is sleeping?
--
Debian testing amd64

--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87k3ve4pyk.fsf@yun.yagibdah.de">http://lists.debian.org/87k3ve4pyk.fsf@yun.yagibdah.de

why would fdisk -l take so long?

Could it be a missing swap partition is slowing down drive access? I
don't know if you were connected to the internet when you did this run,
but if so, you might disconnect from the internet and run fdisk -l again
and compare speeds. It could be fdisk is checking for remote disks as
well but I don't know that for sure. hth.

---------------------------------------------------------------------------
jude <jdashiel@shellworld.net> Adobe fiend for failing to Flash

--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: alpine.BSF.2.01.1209280326270.86982@freire1.furyyj beyq.arg">http://lists.debian.org/alpine.BSF.2.01.1209280326270.86982@freire1.furyyj beyq.arg

why would fdisk -l take so long?

Hi

On Fri, Sep 28, 2012 at 03:52:26AM +0100, Albretch Mueller wrote:
> $ date; fdisk -l; date
> Thu Sep 27 22:48:21 UTC 2012
>
> Disk /dev/sda: 250.1 GB, 250059350016 bytes
> 255 heads, 63 sectors/track, 30401 cylinders, total 488397168 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier: 0x00052568
>
> Device Boot Start End Blocks Id System
> /dev/sda1 63 39086144 19543041 c W95 FAT32 (LBA)
> /dev/sda2 39086145 78140159 19527007+ c W95 FAT32 (LBA)
> /dev/sda3 78140160 234420479 78140160 83 Linux
> /dev/sda4 234420480 488396799 126988160 5 Extended
> /dev/sda5 234420543 353429999 59504728+ c W95 FAT32 (LBA)
> /dev/sda6 353430063 372981104 9775521 c W95 FAT32 (LBA)
> /dev/sda7 372981168 392516144 9767488+ c W95 FAT32 (LBA)
> /dev/sda8 392516208 431570159 19526976 83 Linux
> /dev/sda9 431570223 441353744 4891761 83 Linux
> /dev/sda10 441353808 446253569 2449881 83 Linux
> /dev/sda11 446253633 449819999 1783183+ 83 Linux
> /dev/sda12 449822720 488396799 19287040 83 Linux
> Thu Sep 27 22:48:59 UTC 2012

So... fdisk -l took 38 seconds - which is a bit much.

Question: How long does "fdisk -l /dev/sda" take? (note: specifying
"/dev/sda" explicitly, rather than fdisk figure it out)

If this is a lot shorter, then your problem may be related to how
fdisk chooses a default device to look at, and the contents of
/proc/partitions becomes interesting...

Hope this help
--
Karl E. Jorgensen

--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20120928103027.GA7383@hawking

why would fdisk -l take so long?

> Failing boot sector?
> Some other sector it has to read is failing?
> Check the logs. Try (from smartmontools):
~
I don't know exactly which of your questions/suggestions running:
~
smartctl -A /dev/sda | egrep -i "sector|realloc"
~
relates to, but it didn't report any error message. Without grep I got:
~
$ sudo smartctl -A /dev/sda
smartctl 5.43 2012-05-01 r3539 [i686-linux-3.3.7] (local build)
Copyright (C) 2002-12 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE
UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 115 082 006 Pre-fail
Always - 96695847
3 Spin_Up_Time 0x0003 096 095 000 Pre-fail
Always - 0
4 Start_Stop_Count 0x0032 100 100 020 Old_age
Always - 365
5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail
Always - 0
7 Seek_Error_Rate 0x000f 075 060 030 Pre-fail
Always - 17316569764
9 Power_On_Hours 0x0032 097 097 000 Old_age
Always - 2678
10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail
Always - 0
12 Power_Cycle_Count 0x0032 100 100 020 Old_age
Always - 395
187 Reported_Uncorrect 0x0032 100 100 000 Old_age
Always - 0
189 High_Fly_Writes 0x003a 100 100 000 Old_age
Always - 0
190 Airflow_Temperature_Cel 0x0022 059 045 045 Old_age
Always In_the_past 41 (Min/Max 40/41)
194 Temperature_Celsius 0x0022 041 055 000 Old_age
Always - 41 (0 23 0 0 0)
195 Hardware_ECC_Recovered 0x001a 078 057 000 Old_age
Always - 102323103
197 Current_Pending_Sector 0x0012 100 100 000 Old_age
Always - 0
198 Offline_Uncorrectable 0x0010 100 100 000 Old_age
Offline - 0
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age
Always - 0
200 Multi_Zone_Error_Rate 0x0000 100 253 000 Old_age
Offline - 0
202 Data_Address_Mark_Errs 0x0032 100 253 000 Old_age
Always - 0

$

> Because your disk is sleeping?
~
That I think may be the reason why. I did notice and check that it
always seems to happen after suspending my box, even if you unmount
all drives before, but what I don't get is that may people would be
complaining about that same problem. I have seem people complaining
all the time about hardware-related issues with suspending a box, but
not such delays and I always thought when you awaken your box after
suspending it, it should go to its initial state. Is there a way to
"awaken" all harddrive/partitions you are using?
~
> Could it be a missing swap partition is slowing down drive access?
~
$ cat /proc/swaps
Filename Type Size Used Priority
/dev/zram0 partition 1942352 0 0
~
> I don't know if you were connected to the internet
~
I wasn't, but I have notice weird things happening when I am and, of
course, my work horse box I don't connect to the Internet at all
~
> So... fdisk -l took 38 seconds - which is a bit much.
~
Yep! Exactly 38 seconds!?!
~
$ date; fdisk -l; date
Fri Sep 28 07:13:45 UTC 2012

Disk /dev/sda: 250.1 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders, total 488397168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00052568

Device Boot Start End Blocks Id System
/dev/sda1 63 39086144 19543041 c W95 FAT32 (LBA)
/dev/sda2 39086145 78140159 19527007+ c W95 FAT32 (LBA)
/dev/sda3 78140160 234420479 78140160 83 Linux
/dev/sda4 234420480 488396799 126988160 5 Extended
/dev/sda5 234420543 353429999 59504728+ c W95 FAT32 (LBA)
/dev/sda6 353430063 372981104 9775521 c W95 FAT32 (LBA)
/dev/sda7 372981168 392516144 9767488+ c W95 FAT32 (LBA)
/dev/sda8 392516208 431570159 19526976 83 Linux
/dev/sda9 431570223 441353744 4891761 83 Linux
/dev/sda10 441353808 446253569 2449881 83 Linux
/dev/sda11 446253633 449819999 1783183+ 83 Linux
/dev/sda12 449822720 488396799 19287040 83 Linux
Fri Sep 28 07:14:23 UTC 2012
knoppix@Microknoppix:~$ date; fdisk -l; date
Fri Sep 28 07:14:41 UTC 2012

Disk /dev/sda: 250.1 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders, total 488397168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00052568

Device Boot Start End Blocks Id System
/dev/sda1 63 39086144 19543041 c W95 FAT32 (LBA)
/dev/sda2 39086145 78140159 19527007+ c W95 FAT32 (LBA)
/dev/sda3 78140160 234420479 78140160 83 Linux
/dev/sda4 234420480 488396799 126988160 5 Extended
/dev/sda5 234420543 353429999 59504728+ c W95 FAT32 (LBA)
/dev/sda6 353430063 372981104 9775521 c W95 FAT32 (LBA)
/dev/sda7 372981168 392516144 9767488+ c W95 FAT32 (LBA)
/dev/sda8 392516208 431570159 19526976 83 Linux
/dev/sda9 431570223 441353744 4891761 83 Linux
/dev/sda10 441353808 446253569 2449881 83 Linux
/dev/sda11 446253633 449819999 1783183+ 83 Linux
/dev/sda12 449822720 488396799 19287040 83 Linux
Fri Sep 28 07:15:19 UTC 2012
~
> Question: How long does "fdisk -l /dev/sda" take? (note: specifying
"/dev/sda" explicitly, rather than fdisk figure it out)
~
knoppix@Microknoppix:~$ date; fdisk -l /dev/sda; date
Fri Sep 28 07:15:38 UTC 2012

Disk /dev/sda: 250.1 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders, total 488397168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00052568

Device Boot Start End Blocks Id System
/dev/sda1 63 39086144 19543041 c W95 FAT32 (LBA)
/dev/sda2 39086145 78140159 19527007+ c W95 FAT32 (LBA)
/dev/sda3 78140160 234420479 78140160 83 Linux
/dev/sda4 234420480 488396799 126988160 5 Extended
/dev/sda5 234420543 353429999 59504728+ c W95 FAT32 (LBA)
/dev/sda6 353430063 372981104 9775521 c W95 FAT32 (LBA)
/dev/sda7 372981168 392516144 9767488+ c W95 FAT32 (LBA)
/dev/sda8 392516208 431570159 19526976 83 Linux
/dev/sda9 431570223 441353744 4891761 83 Linux
/dev/sda10 441353808 446253569 2449881 83 Linux
/dev/sda11 446253633 449819999 1783183+ 83 Linux
/dev/sda12 449822720 488396799 19287040 83 Linux
Fri Sep 28 07:15:38 UTC 2012
~
> If this is a lot shorter, then your problem may be related to how
> fdisk chooses a default device to look at, and the contents of
> /proc/partitions becomes interesting...
~
knoppix@Microknoppix:~$ cat /proc/partitions
major minor #blocks name

240 0 9740032 cloop0
251 0 1942356 zram0
8 0 244198584 sda
8 1 19543041 sda1
8 2 19527007 sda2
8 3 78140160 sda3
8 4 1 sda4
8 5 59504728 sda5
8 6 9775521 sda6
8 7 9767488 sda7
8 8 19526976 sda8
8 9 4891761 sda9
8 10 2449881 sda10
8 11 1783183 sda11
8 12 19287040 sda12
11 0 4084128 sr0
2 0 4 fd0
knoppix@Microknoppix:~$
~
So, I guess my questions are"
~
What is going on here?
~
How do you make sure your disks are safely awakened after your system
awakens from "suspended" mode?
~
and by the way I am on:
~
$ uname -a
Linux Microknoppix 3.3.7 #38 SMP PREEMPT Tue May 22 06:21:01 CEST 2012
i686 GNU/Linux
~
and I need to use "fdisk -l" as part of a script that uses the "Disk
identifier" as part of the name of the log file. Can you get the "Disk
identifier" any other (somewhat) -standard- way?
~
lbrtchx

--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/CAFakBwigBJXAid=fvEzwbOX_vSHoGWWD0iPY69cVoGxMzWobW Q@mail.gmail.com

why would fdisk -l take so long?

On 28/09/12 11:30, Karl E. Jorgensen wrote:

Hi

On Fri, Sep 28, 2012 at 03:52:26AM +0100, Albretch Mueller wrote:

$ date; fdisk -l; date
Thu Sep 27 22:48:21 UTC 2012

Disk /dev/sda: 250.1 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders, total 488397168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00052568

Device Boot Start End Blocks Id System
/dev/sda1 63 39086144 19543041 c W95 FAT32 (LBA)
/dev/sda2 39086145 78140159 19527007+ c W95 FAT32 (LBA)
/dev/sda3 78140160 234420479 78140160 83 Linux
/dev/sda4 234420480 488396799 126988160 5 Extended
/dev/sda5 234420543 353429999 59504728+ c W95 FAT32 (LBA)
/dev/sda6 353430063 372981104 9775521 c W95 FAT32 (LBA)
/dev/sda7 372981168 392516144 9767488+ c W95 FAT32 (LBA)
/dev/sda8 392516208 431570159 19526976 83 Linux
/dev/sda9 431570223 441353744 4891761 83 Linux
/dev/sda10 441353808 446253569 2449881 83 Linux
/dev/sda11 446253633 449819999 1783183+ 83 Linux
/dev/sda12 449822720 488396799 19287040 83 Linux
Thu Sep 27 22:48:59 UTC 2012

So... fdisk -l took 38 seconds - which is a bit much.

Question: How long does "fdisk -l /dev/sda" take? (note: specifying
"/dev/sda" explicitly, rather than fdisk figure it out)

If this is a lot shorter, then your problem may be related to how
fdisk chooses a default device to look at, and the contents of
/proc/partitions becomes interesting...

Hope this help

Also, try using "time fdisk -l". The time command gives a slightly
better idea of where the time is being spent that just using date before
and after.

--
Dom

--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: 50659554.5060808@rpdom.net">http://lists.debian.org/50659554.5060808@rpdom.net

why would fdisk -l take so long?

On 28/09/12 12:27, Albretch Mueller wrote:

Failing boot sector?
Some other sector it has to read is failing?
Check the logs. Try (from smartmontools):

~
I don't know exactly which of your questions/suggestions running:
~
smartctl -A /dev/sda | egrep -i "sector|realloc"
~
relates to, but it didn't report any error message. Without grep I got:
~
$ sudo smartctl -A /dev/sda
smartctl 5.43 2012-05-01 r3539 [i686-linux-3.3.7] (local build)
Copyright (C) 2002-12 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE
UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 115 082 006 Pre-fail
Always - 96695847

Ok, your disk is dying. The Raw_Read_Error_Rate should be zero, or very low.

7 Seek_Error_Rate 0x000f 075 060 030 Pre-fail
Always - 17316569764

That is also seriously bad.

9 Power_On_Hours 0x0032 097 097 000 Old_age
Always - 2678

Is this a fairly new disk? Only 2678 hours use.

195 Hardware_ECC_Recovered 0x001a 078 057 000 Old_age
Always - 102323103

It looks like many errors have been recovered using ECC, so you probably
wouldn't have noticed those.

It *is* possible that smartctl is mis-interpretting the status of your
disk, but given your slow fdisk command I suspect not.

Time to backup, backup, backup, buy a new disk and transfer the data
over asap.

--
Dom

--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: 506596DF.7030002@rpdom.net">http://lists.debian.org/506596DF.7030002@rpdom.net

why would fdisk -l take so long?

On Fri, Sep 28, 2012 at 01:23:59PM +0100, Dom wrote:
> It *is* possible that smartctl is mis-interpretting the status of
> your disk, but given your slow fdisk command I suspect not.
>
> Time to backup, backup, backup, buy a new disk and transfer the data
> over asap.

YES to backup, but it's worth changing your SATA cable before investing
in a new disk, or at least ensuring your current one is seated properly.
Try to measure the *rate* that Hardware_ECC_Recovered is increasing over
a set period of time, check/replace cable, measure again.

--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20120928125241.GD5503@debian

why would fdisk -l take so long?

Albretch Mueller <lbrtchx@gmail.com> writes:

>> Because your disk is sleeping?
> ~
> That I think may be the reason why. I did notice and check that it
> always seems to happen after suspending my box, even if you unmount
> all drives before, but what I don't get is that may people would be
> complaining about that same problem. I have seem people complaining
> all the time about hardware-related issues with suspending a box, but
> not such delays and I always thought when you awaken your box after
> suspending it, it should go to its initial state.

It should go back to where you suspended or hibernated it, and it
doesn't. If your disk is sleeping because its power management decided
to turn it off, it can take a while for it to wake up. It might be a
good idea to check the power management settings with something like
hdparm.

> Is there a way to "awaken" all harddrive/partitions you are using?

fdisk -l seems to do that. However, it's difficult to reasonably put to
sleep a disk which has partitions on it that are mounted, and it's very
questionable if it's reasonable to do so (unless it's an SSD maybe, if
those can be put to sleep at all).

How much money and energy do you actually save by putting disks to sleep
when you consider the possibility of increased wear and perhaps having
to replace them sooner than would otherwise be necessary? Are there any
good studies aimed to answer this question?

--
Debian testing amd64

--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87txui2sgj.fsf@yun.yagibdah.de">http://lists.debian.org/87txui2sgj.fsf@yun.yagibdah.de