$ 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
09-28-2012, 03:47 AM
Neal Murphy
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
09-28-2012, 06:32 AM
lee
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
09-28-2012, 07:29 AM
Jude DaShiell
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
09-28-2012, 10:30 AM
"Karl E. Jorgensen"
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
09-28-2012, 11:27 AM
Albretch Mueller
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
> 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
09-28-2012, 12:17 PM
Dom
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
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.
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
09-28-2012, 01:21 PM
lee
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
why would fdisk -l take so long?
