Re: why would fdisk -l take so long?
On 9/29/12, Martin Steigerwald wrote: > Hi Albrecht! > > Am Samstag, 29. September 2012 schrieb Albretch Mueller: > > Two ideas: > > 1) floppy device activated in BIOS while no floppy device present > > 2) floppy emulation for USB mass storage activated in BIOS ~ that was it! Reset, checked and solved! ~ thank you Martin et al lbrtchx -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAFakBwgGtMMFAja1zP8_0X=1qg8Wsf_NKQF=q_cqpts2od1...@mail.gmail.com
Re: why would fdisk -l take so long?
On 9/29/12, Jude DaShiell wrote: > run d-ban on the disk and do a thorough cleaning of the disk then try ~ The only "data erasure" I know of is shredding your hard drives to pieces, smashing them to dust and melting them. This is by the way what US gov does with their hard drives and monitors ~ lbrtchx ~ http://en.wikipedia.org/wiki/Hysteresis ~ http://en.wikipedia.org/wiki/Data_remanence ~ http://en.wikipedia.org/wiki/Coercivity ~ http://en.wikipedia.org/wiki/Degaussing For certain forms of computer data storage, however, such as modern hard drives and some tape backup drives, degaussing renders the magnetic media completely unusable and damages the storage system. This is due to the devices having an infinitely variable read/write head positioning mechanism which relies on special servo control data (e.g. Gray Code) that is meant to be permanently embedded into the magnetic media. This servo data is written onto the media a single time at the factory using special-purpose servo writing hardware. The servo patterns are normally never overwritten by the device for any reason and are used to precisely position the read/write heads over data tracks on the media, to compensate for sudden jarring device movements, thermal expansion, or changes in orientation. Degaussing indiscriminately removes not only the stored data but also the servo control data, and without the servo data the device is no longer able to determine where data is to be read or written on the magnetic medium. The medium must be low-level formatted to become usable again; with modern hard drives, this is generally not possible without manufacturer-specific and often model-specific service equipment. ~ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAFakBwj=pS0AT98ZjzPF1uVJ_X4NH=isxr4w1pavamvofd_...@mail.gmail.com
Re: why would fdisk -l take so long?
Hi Albrecht! Am Samstag, 29. September 2012 schrieb Albretch Mueller: […] > [11750.572197] ata2: SATA link down (SStatus 0 SControl 300) > [11750.572245] ata1: SATA link down (SStatus 0 SControl 300) > [11750.676244] ata3.00: ACPI cmd ef/03:0c:00:00:00:a0 (SET FEATURES) > filtered out > [11750.676248] ata3.00: ACPI cmd ef/03:42:00:00:00:a0 (SET FEATURES) > filtered out > [11750.676252] ata3.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE > LOCK) filtered out > [11750.682804] ata3.00: configured for UDMA/33 > [11755.300321] psmouse serio1: hgpk: ID: 10 00 64 > [11757.745503] > [11757.745504] floppy driver state > [11757.745505] --- > [11757.745513] now=3437324 last interrupt=1109734 diff=2327590 last > called handler=recal_interrupt > [11757.745515] timeout_message=lock fdc > [11757.745517] last output bytes: > [11757.745518] 18 80 4294884748 > [11757.745520] 8 80 4294884748 > [11757.745522] 8 80 4294884748 > [11757.745523] 8 80 4294884748 > [11757.745525] 8 80 4294884748 > [11757.745527] 12 80 1109103 > [11757.745528] 0 90 1109103 > [11757.745530] 13 90 1109103 > [11757.745531] 0 90 1109103 > [11757.745533] 1a 90 1109103 > [11757.745534] 0 90 1109103 > [11757.745536] 3 80 1109103 > [11757.745537] c1 90 1109103 > [11757.745539] 10 90 1109103 > [11757.745540] 7 80 1109103 > [11757.745542] 0 90 1109103 > [11757.745544] 8 81 1109416 > [11757.745545] 7 80 1109422 > [11757.745547] 0 90 1109422 > [11757.745548] 8 81 1109734 > [11757.745550] last result at 1109734 > [11757.745551] last redo_fd_request at 1121152 > [11757.745554] 70 00p. > [11757.745564] status=0 > [11757.745566] fdc_busy=1 > [11757.745569] do_floppy=reset_interrupt > [11757.745571] cont=f85786c8 > [11757.745572] current_req= (null) > [11757.745574] command_status=-1 > [11757.745575] > [11757.745578] floppy0: floppy timeout called > [11757.745604] PM: resume of devices complete after 7495.396 msecs > [11757.745866] Restarting tasks ... done. > [11758.374389] VFS: busy inodes on changed media or resized disk sr0 > [11758.376145] ADDRCONF(NETDEV_UP): eth0: link is not ready > [11760.048064] tg3 :02:00.0: eth0: Link is up at 100 Mbps, full duplex > [11760.048068] tg3 :02:00.0: eth0: Flow control is on for TX and on for RX > [11760.048247] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready > [11770.228921] eth0: no IPv6 routers present > [11952.768836] usb 1-8: new high-speed USB device number 4 using ehci_hcd > [11952.898331] usb 1-8: New USB device found, idVendor=0930, idProduct=6545 > [11952.898334] usb 1-8: New USB device strings: Mfr=1, Product=2, > SerialNumber=3 > [11952.898337] usb 1-8: Product: DT 101 G2 > [11952.898340] usb 1-8: Manufacturer: Kingston > [11952.898342] usb 1-8: SerialNumber: 001CC0C83B35EB61142A011A > [11952.899440] scsi6 : usb-storage 1-8:1.0 > [11953.948116] scsi 6:0:0:0: Direct-Access Kingston DT 101 G2 > PMAP PQ: 0 ANSI: 0 CCS > [11953.948296] sd 6:0:0:0: Attached scsi generic sg1 type 0 > [11954.607947] sd 6:0:0:0: [sda] 15638528 512-byte logical blocks: > (8.00 GB/7.45 GiB) > [11954.610064] sd 6:0:0:0: [sda] Write Protect is off > [11954.610068] sd 6:0:0:0: [sda] Mode Sense: 23 00 00 00 > [11954.612344] sd 6:0:0:0: [sda] No Caching mode page present > [11954.612347] sd 6:0:0:0: [sda] Assuming drive cache: write through > [11954.619566] sd 6:0:0:0: [sda] No Caching mode page present > [11954.619569] sd 6:0:0:0: [sda] Assuming drive cache: write through > [11954.641593] sda: sda1 > [11954.647337] sd 6:0:0:0: [sda] No Caching mode page present > [11954.647342] sd 6:0:0:0: [sda] Assuming drive cache: write through > [11954.647345] sd 6:0:0:0: [sda] Attached SCSI removable disk > [12011.869055] end_request: I/O error, dev fd0, sector 0 > [12097.222509] end_request: I/O error, dev fd0, sector 0 > [12150.892906] end_request: I/O error, dev fd0, sector 0 > [12209.992320] end_request: I/O error, dev fd0, sector 0 > [22999.715096] usb 1-8: USB disconnect, device number 4 > [22999.974401] usb 1-8: new high-speed USB device number 5 using ehci_hcd > [23000.494403] usb 1-8: device not accepting address 5, error -71 > [23000.547764] hub 1-0:1.0: unable to enumerate USB device on port 8 > [23431.424360] usb 1-8: new high-speed USB device number 7 using ehci_hcd > [23431.553861] usb 1-8: New USB device found, idVendor=0930, idProduct=6545 > [23431.553866] usb 1-8: New USB device strings: Mfr=1, Product=2, > SerialNumber=3 > [23431.553869] usb 1-8: Product: DT 101 G2 > [23431.553871] usb 1-8: Manufacturer: Kingston > [23431.553874] usb 1-8: SerialNumber: 001CC0C83B35EB61142A011A > [23431.555077] scsi7 : usb-storage 1-8:1.0 > [23432.603528] scsi 7:0:0:0: Direct-Access Kingston DT 101 G2 > PMAP PQ: 0 ANSI: 0 CCS > [23432.603703] sd 7:0:0:0: Attached scsi generic sg1 type 0 > [23433.241968] sd 7:0:0:0: [sda] 15638528 512-byte logical blocks: > (8.00 GB/7.45 GiB) > [23433.244088] sd 7:0:0:0: [sda] Write Protect is off > [23433.244091] sd 7:0
Re: why would fdisk -l take so long?
> Or (from hdparm's man page: Disable the automatic power-saving > function of certain Seagate drives...): > hdparm -Z /dev/sda # hdparm -Z /dev/sda /dev/sda: disabling Seagate auto powersaving mode HDIO_DRIVE_CMD(seagatepwrsave) failed: Input/output error lbrtchx -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cafakbwjz5c7lhwsegnntlk4ldc2dsuurbexdlvjnfguzn9z...@mail.gmail.com
Re: why would fdisk -l take so long?
~ I think there may be a number of things going on here. Let me first answer Neal's questions: ~ > Have you tried "fdisk -l /dev/sda"? ~ Well, there are no disk attached whatsoever to my box. I am using a bear live CD (knoppix 7.0.2) right off the DVD drive ~ > How about: > tail -f /var/log/messages # In a separate window ~ file seems to be empty ~ $ date; time sudo ls -l /KNOPPIX/var/log/messages Fri Sep 28 21:55:38 UTC 2012 -rw-r- 1 syslog adm 0 May 13 02:17 /KNOPPIX/var/log/messages real0m0.012s user0m0.000s sys 0m0.007s ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Without having any drive attached I booted into init 2 using: ~ "boot: knoppix no3d init 2" ~ and fdisk -l was returning with timings bellow 0.010s. Then I suspended the box (again no hard drives attached whatsoever) and after awakening the box "fdisk -l" started giving me the "38+ seconds" responses ~ So it may not be a hard drive dying issue after all. Am I the only debian user suspending his box to whom that happens? ~ lbrtchx ~ $ date; time fdisk -l Fri Sep 28 21:14:08 UTC 2012 real 0m0.009s $ date; time fdisk -l Fri Sep 28 21:14:10 UTC 2012 real 0m0.009s $ date; time fdisk -l Fri Sep 28 21:14:11 UTC 2012 real 0m0.009s sys 0m0.003s $ date; time fdisk -l Fri Sep 28 21:14:12 UTC 2012 real 0m0.009s $ sudo mount /media/sda1 $ date; time fdisk -l Fri Sep 28 21:14:45 UTC 2012 Disk /dev/sda: 8006 MB, 8006926336 bytes 39 heads, 39 sectors/track, 10281 cylinders, total 15638528 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: 0xc3072e18 Device Boot Start End Blocks Id System /dev/sda1 *806415638527 7815232c W95 FAT32 (LBA) real 0m0.017s $ date; time fdisk -l Fri Sep 28 21:14:49 UTC 2012 Disk /dev/sda: 8006 MB, 8006926336 bytes 39 heads, 39 sectors/track, 10281 cylinders, total 15638528 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: 0xc3072e18 Device Boot Start End Blocks Id System /dev/sda1 *806415638527 7815232c W95 FAT32 (LBA) real 0m0.015s $ date; time fdisk -l Fri Sep 28 21:14:50 UTC 2012 Disk /dev/sda: 8006 MB, 8006926336 bytes 39 heads, 39 sectors/track, 10281 cylinders, total 15638528 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: 0xc3072e18 Device Boot Start End Blocks Id System /dev/sda1 *806415638527 7815232c W95 FAT32 (LBA) real 0m0.013s $ date; time fdisk -l Fri Sep 28 21:14:51 UTC 2012 Disk /dev/sda: 8006 MB, 8006926336 bytes 39 heads, 39 sectors/track, 10281 cylinders, total 15638528 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: 0xc3072e18 Device Boot Start End Blocks Id System /dev/sda1 *806415638527 7815232c W95 FAT32 (LBA) real 0m0.014s $ sudo umount /media/sda1 $ date; time fdisk -l Fri Sep 28 21:15:02 UTC 2012 Disk /dev/sda: 8006 MB, 8006926336 bytes 39 heads, 39 sectors/track, 10281 cylinders, total 15638528 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: 0xc3072e18 Device Boot Start End Blocks Id System /dev/sda1 *806415638527 7815232c W95 FAT32 (LBA) real 0m0.025s user 0m0.003s $ date; time fdisk -l Fri Sep 28 21:15:03 UTC 2012 Disk /dev/sda: 8006 MB, 8006926336 bytes 39 heads, 39 sectors/track, 10281 cylinders, total 15638528 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: 0xc3072e18 Device Boot Start End Blocks Id System /dev/sda1 *806415638527 7815232c W95 FAT32 (LBA) real 0m0.022s $ date; time fdisk -l Fri Sep 28 21:15:04 UTC 2012 Disk /dev/sda: 8006 MB, 8006926336 bytes 39 heads, 39 sectors/track, 10281 cylinders, total 15638528 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: 0xc3072e18 Device Boot Start End Blocks Id System /dev/sda1 *806415638527 7815232c W95 FAT32 (LBA) real 0m0.024s $ date; time fdisk -l Fri Sep 28 21:15:04 UTC 2012 Disk /dev/sda: 8006 MB, 8006926336 bytes 39 heads, 39 sectors/track, 10281 cylinders, total 15638528 sectors Units = sectors of 1 * 512
Re: why would fdisk -l take so long?
On Friday, September 28, 2012 08:58:47 PM Albretch Mueller wrote: > > > >1 Raw_Read_Error_Rate 0x000f 115 082 006Pre-fail > > > > > > > > Always - 96695847 > > > > > > Ok, your disk is dying. The Raw_Read_Error_Rate should be zero, or very > > > low. > > > > Not necessarily. At least one disk mfr (Seagate?) puts large values in > > these fields. Cause me a few moments' consternation the first time I saw > > it on my own drives > > ~ > Indeed! Something "spooky" may be going on. After taking the drive > out in order to back it up, I have run "fdisk -l" with no disk and > sometimes with a pen drive inserted and these bellow are the results I > got. > ~ > Don't you find all of this downright weird? Not yet. > ~ > I don't believe in ghosts ;-) What do you think I could do to > troubleshoot this further? Have you tried "fdisk -l /dev/sda"? I think you did, to no avail. It might be searching some other drive or type of drive first that is slow to respond. Check the drive's power state: hdparm -C /dev/sda How about: tail -f /var/log/messages # In a separate window time dd if=/dev/sda of=/dev/null bs=1024k count=1 time fdisk -l /dev/sda to see if the drive is dozing. Or (from hdparm's man page: Disable the automatic power-saving function of certain Seagate drives...): hdparm -Z /dev/sda -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201209282134.29827.neal.p.mur...@alum.wpi.edu
Re: why would fdisk -l take so long?
> > >1 Raw_Read_Error_Rate 0x000f 115 082 006Pre-fail
> > >
> > > Always - 96695847
> >
> > Ok, your disk is dying. The Raw_Read_Error_Rate should be zero, or very
> > low.
> Not necessarily. At least one disk mfr (Seagate?) puts large values in these
> fields. Cause me a few moments' consternation the first time I saw it on my
> own drives
~
Indeed! Something "spooky" may be going on. After taking the drive
out in order to back it up, I have run "fdisk -l" with no disk and
sometimes with a pen drive inserted and these bellow are the results I
got.
~
Don't you find all of this downright weird?
~
I don't believe in ghosts ;-) What do you think I could do to
troubleshoot this further?
~
lbrtchx
~
$ time fdisk -l
Disk /dev/sda: 8006 MB, 8006926336 bytes
39 heads, 39 sectors/track, 10281 cylinders, total 15638528 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: 0xc3072e18
Device Boot Start End Blocks Id System
/dev/sda1 *806415638527 7815232c W95 FAT32 (LBA)
real0m38.106s
user0m0.000s
sys 0m0.000s
$ mount /media/sda1
$ time fdisk -l
konqueror(2828)/kdecore (KLibrary) findLibraryInternal: plugins should
not have a 'lib' prefix: "libkhtmlpart.so"
konqueror(2828)/kdecore (KLibrary) kde4Factory: The library
"/usr/lib/kde4/khtml_kget.so" does not offer a qt_plugin_instance
function.
Disk /dev/sda: 8006 MB, 8006926336 bytes
39 heads, 39 sectors/track, 10281 cylinders, total 15638528 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: 0xc3072e18
Device Boot Start End Blocks Id System
/dev/sda1 *806415638527 7815232c W95 FAT32 (LBA)
real0m38.107s
user0m0.000s
sys 0m0.000s
$ sudo umount /media/sda1
$ time fdisk -l
real0m38.314s
user0m0.000s
sys 0m0.000s
$ _DT=`date +%Y%m%d%H%M%S`; dmesg > dmesg_${_DT}.log
$ date; time fdisk -l; date
Fri Sep 28 20:51:09 UTC 2012
real0m38.097s
user0m0.000s
sys 0m0.000s
Fri Sep 28 20:51:47 UTC 2012
$ _DT=`date +%Y%m%d%H%M%S`; dmesg > dmesg_${_DT}.log
$ ls -l dmesg_*.log
-rw-r--r-- 1 knoppix knoppix 15493 Sep 28 20:50 dmesg_20120928205055.log
-rw-r--r-- 1 knoppix knoppix 15490 Sep 28 20:51 dmesg_20120928205157.log
$ wc -l dmesg_*.log
298 dmesg_20120928205055.log
299 dmesg_20120928205157.log
597 total
$ diff dmesg_20120928205055.log dmesg_20120928205157.log
1c1
< 090] ehci_hcd :00:13.2: wake-up capability enabled by ACPI
---
> PI
298a299
> [26607.877660] end_request: I/O error, dev fd0, sector 0
$
$ cat dmesg_20120928205055.log
090] ehci_hcd :00:13.2: wake-up capability enabled by ACPI
[ 4008.172988] ohci_hcd :00:13.1: wake-up capability enabled by ACPI
[ 4008.173025] ohci_hcd :00:13.0: wake-up capability enabled by ACPI
[ 4008.173066] PM: late suspend of devices complete after 13.416 msecs
[ 4008.173239] ACPI: Preparing to enter system sleep state S3
[ 4008.173322] PM: Saving platform NVS memory
[ 4008.173361] Disabling non-boot CPUs ...
[ 4008.173361] ACPI: Low-level resume complete
[ 4008.173361] PM: Restoring platform NVS memory
[ 4008.173361] ACPI: Waking up from system sleep state S3
[ 4008.173361] ohci_hcd :00:13.0: wake-up capability disabled by ACPI
[ 4008.173361] ohci_hcd :00:13.1: wake-up capability disabled by ACPI
[ 4008.173361] ehci_hcd :00:13.2: wake-up capability disabled by ACPI
[ 4008.173361] PM: early resume of devices complete after 0.718 msecs
[ 4008.176363] pci:00: wake-up capability disabled by ACPI
[ 4008.176442] radeon :01:00.0: f529d800 unpin not necessary
[ 4008.178326] serial 00:08: activated
[ 4008.178771] parport_pc 00:09: activated
[ 4008.189307] [drm] radeon: 1 quad pipes, 1 z pipes initialized.
[ 4008.201519] [drm] PCIE GART of 512M enabled (table at 0x0004).
[ 4008.201531] radeon :01:00.0: WB enabled
[ 4008.201534] [drm] fence driver on ring 0 use gpu addr 0x1000
and cpu addr 0xff885000
[ 4008.201621] [drm] radeon: ring at 0x10001000
[ 4008.201651] [drm] ring test succeeded in 7 usecs
[ 4008.201667] [drm] ib test succeeded in 0 usecs
[ 4008.496304] ata2: SATA link down (SStatus 0 SControl 300)
[ 4008.496352] ata1: SATA link down (SStatus 0 SControl 300)
[ 4008.600352] ata3.00: ACPI cmd ef/03:0c:00:00:00:a0 (SET FEATURES)
filtered out
[ 4008.600356] ata3.00: ACPI cmd ef/03:42:00:00:00:a0 (SET FEATURES)
filtered out
[ 4008.600360] ata3.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE
LOCK) filtered out
[ 4008.606911] ata3.00: configured for UDMA/33
[ 4013.233591] psmouse serio1: hgpk: ID: 10 00 64
[ 4015.679626]
[ 4015.679628] floppy driver state
[ 4015.679629] ---
[ 4015.679637] now=1114704 last interrupt=1109734 diff=4970 last
called handler=
Re: why would fdisk -l take so long?
On Friday, September 28, 2012 08:23:59 AM Dom wrote: > >1 Raw_Read_Error_Rate 0x000f 115 082 006Pre-fail > > > > Always - 96695847 > > Ok, your disk is dying. The Raw_Read_Error_Rate should be zero, or very > low. Not necessarily. At least one disk mfr (Seagate?) puts large values in these fields. Cause me a few moments' consternation the first time I saw it on my own drives -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201209281448.32568.neal.p.mur...@alum.wpi.edu
Re: why would fdisk -l take so long?
in a box in which I use the fromhd stanza using a disk which smartclt reports as being fine the results before and after suspending are the same ~ this is what the dying disk reports ~ $ date; X=`(time fdisk -l) 2>&1 | grep real`; echo $X Fri Sep 28 10:52:58 UTC 2012 real 0m0.191s $ date; X=`(time fdisk -l) 2>&1 | grep real`; echo $X Fri Sep 28 10:52:59 UTC 2012 real 0m0.055s $ date; X=`(time fdisk -l) 2>&1 | grep real`; echo $X Fri Sep 28 10:53:00 UTC 2012 real 0m0.052s ~ it then stabilize around 0.050s ~ For the good ones time consistently reports 0.003s ~ the thing is (for more than one reason) I use a crappy box to go online ~ Also, any comprehensive documentation regarding hd's health? smartctl's is OK to get by, but you are telling me about logs I don't know about and I would like to know more about the physics of it ~ lbrtchx -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAFakBwjq=rD5G_SRLx=j7wakoctyp2nua9xgk-yeygexds1...@mail.gmail.com
Re: why would fdisk -l take so long?
On 28/09/12 13:52, Jon Dowland wrote: 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. Good points, which I did think of *after* I'd posted my comment. Good catch. :-) -- Dom -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5065bdf9.1040...@rpdom.net
Re: why would fdisk -l take so long?
I just backed up all the data ~ Yet, it seems something else may be (also?) somehow relating to those delays. Since I start knoppix 7.0.2 as: ~ knoppix no3d fromhd=/dev/sda9 ~ could these issues/problems relate to the fact that /dev/sda9 is mounted read-only and knoppix keeps it to itself throughout its running time? ~ See bellow the fdisk -l timings when I run knoppix from the dvd ~ lbrtchx // __ fdisk -l $ date; X=`(time fdisk -l) 2>&1 | grep real`; echo $X Fri Sep 28 10:20:26 UTC 2012 real 0m0.014s $ date; X=`(time fdisk -l) 2>&1 | grep real`; echo $X Fri Sep 28 10:20:28 UTC 2012 real 0m0.012s $ date; X=`(time fdisk -l) 2>&1 | grep real`; echo $X Fri Sep 28 10:20:29 UTC 2012 real 0m0.012s $ date; X=`(time fdisk -l) 2>&1 | grep real`; echo $X Fri Sep 28 10:20:29 UTC 2012 real 0m0.013s // __ fdisk -l /dev/sda $ date; X=`(time fdisk -l /dev/sda) 2>&1 | grep real`; echo $X Fri Sep 28 10:20:35 UTC 2012 real 0m0.002s $ date; X=`(time fdisk -l /dev/sda) 2>&1 | grep real`; echo $X Fri Sep 28 10:20:36 UTC 2012 real 0m0.002s $ date; X=`(time fdisk -l /dev/sda) 2>&1 | grep real`; echo $X Fri Sep 28 10:20:37 UTC 2012 real 0m0.002s $ date; X=`(time fdisk -l /dev/sda) 2>&1 | grep real`; echo $X Fri Sep 28 10:20:38 UTC 2012 real 0m0.002s -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAFakBwhnYgFAoEuuCFf-3oCsKJ+HiN=y4cgxcpefhnwm_vb...@mail.gmail.com
Re: why would fdisk -l take so long?
Albretch Mueller 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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87txui2sgj@yun.yagibdah.de
Re: 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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120928125241.GD5503@debian
Re: 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 006Pre-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 030Pre-fail Always - 17316569764 That is also seriously bad. 9 Power_On_Hours 0x0032 097 097 000Old_age Always - 2678 Is this a fairly new disk? Only 2678 hours use. 195 Hardware_ECC_Recovered 0x001a 078 057 000Old_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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/506596df.7030...@rpdom.net
Re: 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 633908614419543041c W95 FAT32 (LBA) /dev/sda2390861457814015919527007+ c W95 FAT32 (LBA) /dev/sda378140160 23442047978140160 83 Linux /dev/sda4 234420480 488396799 1269881605 Extended /dev/sda5 234420543 3534259504728+ c W95 FAT32 (LBA) /dev/sda6 353430063 372981104 9775521c W95 FAT32 (LBA) /dev/sda7 372981168 392516144 9767488+ c W95 FAT32 (LBA) /dev/sda8 392516208 43157015919526976 83 Linux /dev/sda9 431570223 441353744 4891761 83 Linux /dev/sda10 441353808 446253569 2449881 83 Linux /dev/sda11 446253633 44981 1783183+ 83 Linux /dev/sda12 449822720 48839679919287040 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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50659554.5060...@rpdom.net
Re: 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 006Pre-fail Always - 96695847 3 Spin_Up_Time0x0003 096 095 000Pre-fail Always - 0 4 Start_Stop_Count0x0032 100 100 020Old_age Always - 365 5 Reallocated_Sector_Ct 0x0033 100 100 036Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 075 060 030Pre-fail Always - 17316569764 9 Power_On_Hours 0x0032 097 097 000Old_age Always - 2678 10 Spin_Retry_Count0x0013 100 100 097Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 020Old_age Always - 395 187 Reported_Uncorrect 0x0032 100 100 000Old_age Always - 0 189 High_Fly_Writes 0x003a 100 100 000Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 059 045 045Old_age Always In_the_past 41 (Min/Max 40/41) 194 Temperature_Celsius 0x0022 041 055 000Old_age Always - 41 (0 23 0 0 0) 195 Hardware_ECC_Recovered 0x001a 078 057 000Old_age Always - 102323103 197 Current_Pending_Sector 0x0012 100 100 000Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000Old_age Offline - 0 199 UDMA_CRC_Error_Count0x003e 200 200 000Old_age Always - 0 200 Multi_Zone_Error_Rate 0x 100 253 000Old_age Offline - 0 202 Data_Address_Mark_Errs 0x0032 100 253 000Old_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 FilenameTypeSizeUsedPriority /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 633908614419543041c W95 FAT32 (LBA) /dev/sda2390861457814015919527007+ c W95 FAT32 (LBA) /dev/sda378140160 23442047978140160 83 Linux /dev/sda4 234420480 488396799 1269881605 Extended /dev/sda5 234420543 3534259504728+ c W95 FAT32 (LBA) /dev/sda6 353430063 372981104 9775521c W95 FAT32 (LBA) /dev/sda7 372981168 392516144 9767488+ c W95 FAT32 (LBA) /dev/sda8 392516208 43157015919526976 83 Linux /dev/sda9 431570223 441353744 4891761 83 Linux /dev/sda10 441353808 446253569 2449881 83 Linux /dev/sda11 446253633 44981 1783183+ 83 Linux /dev/sda12 449822720 48839679919287040 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 by
Re: 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 633908614419543041c W95 FAT32 (LBA) > /dev/sda2390861457814015919527007+ c W95 FAT32 (LBA) > /dev/sda378140160 23442047978140160 83 Linux > /dev/sda4 234420480 488396799 1269881605 Extended > /dev/sda5 234420543 3534259504728+ c W95 FAT32 (LBA) > /dev/sda6 353430063 372981104 9775521c W95 FAT32 (LBA) > /dev/sda7 372981168 392516144 9767488+ c W95 FAT32 (LBA) > /dev/sda8 392516208 43157015919526976 83 Linux > /dev/sda9 431570223 441353744 4891761 83 Linux > /dev/sda10 441353808 446253569 2449881 83 Linux > /dev/sda11 446253633 44981 1783183+ 83 Linux > /dev/sda12 449822720 48839679919287040 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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120928103027.GA7383@hawking
Re: 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 Adobe fiend for failing to Flash -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.bsf.2.01.1209280326270.86...@freire1.furyyjbeyq.arg
Re: why would fdisk -l take so long?
Because your disk is sleeping? -- Debian testing amd64 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k3ve4pyk@yun.yagibdah.de
Re: 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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201209272347.31024.neal.p.mur...@alum.wpi.edu
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 633908614419543041c W95 FAT32 (LBA) /dev/sda2390861457814015919527007+ c W95 FAT32 (LBA) /dev/sda378140160 23442047978140160 83 Linux /dev/sda4 234420480 488396799 1269881605 Extended /dev/sda5 234420543 3534259504728+ c W95 FAT32 (LBA) /dev/sda6 353430063 372981104 9775521c W95 FAT32 (LBA) /dev/sda7 372981168 392516144 9767488+ c W95 FAT32 (LBA) /dev/sda8 392516208 43157015919526976 83 Linux /dev/sda9 431570223 441353744 4891761 83 Linux /dev/sda10 441353808 446253569 2449881 83 Linux /dev/sda11 446253633 44981 1783183+ 83 Linux /dev/sda12 449822720 48839679919287040 83 Linux Thu Sep 27 22:48:59 UTC 2012 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cafakbwhihfatiqirsygz-3xk4qnac51fmruttpl6p+cvmly...@mail.gmail.com
