My 160 gb ipod drive (via standard apple ipod usb) is being identified as a 19 gb drive. Based on the speed it reports, and how long its taking, I think it may actually be formatting correctly, but I am curious if this is a known problem in HDDLLF or whether it reflects some issue with my hardware.

TIA

Have you read the warnings about HDDLLF compatibility on its download page? Personally, I wouldn't use that utility, due to those issues...

Why were you using it and what OS does your PC have? Perhaps someone can then recommend an alternative to you.

Well, I read all the information that was available where I obtained it. (http://hddguru.com/software/HDD-LLF-Low ... rmat-Tool/) The only warning (I saw) there (even after rereading) was that it would erase my data - a pretty obvious outcome of formatting.

So if you could point me to the documentation you refer to I would appreciate it greatly. In the mean time, I am using the utility because windows in unable to successfully (low level) format the drive (not fully - it hangs around 25%). Quick format gets the device restored and functional, but still leaves the defects as usable blocks which of course is not ok.

HDLFF does appear to be working aside from the reported size before format - though I see it has slowed substantially in the same zone that normally hangs windows - as I mentioned, but I am trying to improve my understanding in general as I move forward.

I am running windows 32 - bit vista on intel

Incidentally, although I failed to express it, I was grateful for your quick reply. I am usually very good about trying to identify and utilize all available documentation resources, but I can find no obvious usefully related material in any of the areas I looked in. I am beginning to wonder if I am just missing some obvious link or section or something because its strange that I can find 0 stuff.

Thanks again. To u and anyone else helpful.

Thanks for the info.
[
My bad - I see it's recently been updated, and I hadn't noticed, sorry. The program used to be incompatible with Win Vista and later versions, hence my concern...


Windows can never do what is accurately termed a low-level format on a disk (i.e. rewrite the AM & DM on the disk service) through its normal functionality. A low-level format on flash means different things to different people, since the original meaning of a "low level format" on a disk, cannot apply to flash. I guess you're referring to trying a full format which on Win Vista & later, will write to every block in that filesystem.

As I'm not the author of HDDLLF, I don't know exactly what it does - but on any attached USB device (like yours), it's severely limited as to what it can do in order to "format" a disk, other than write to every block (due to limitations in the USB Mass Storage Device protocol). Writing to every block is exactly what Win Vista would also be doing for a full format, as I explained above (although things like number of retries etc. could be different, and hence you might see different results).

Regarding your original question (mis-reporting drive size), I can only suggest requesting support via that new contact form linked to the HDDLLF page, but unless you have paid for a license, I don't know if support is offered. Also, this could be a side-effect of faulty hardware or, to say it another way, this may not be an HDDLLF bug.

If I was in your situation, I would be looking at the Windows Event Log, to see what errors it was logging when the attempt at a Windows full format hangs, but I would not expect that any software (inc HDDLLF) can fix a problem with your hardware, which seems to be what you are describing.

Good flash controllers are supposed to retire faulty NAND blocks (up to their limit of spare blocks) which are detected during writes, so if yours isn't doing that, normal PC software isn't going to fix it, as the PC doesn't (can't) control what is happening at the level of this type of flash - perhaps your iPod has already reached its limit of spare pages... (Some flash controllers have specific PC utilities which can be used to force them to test their attached flash via vendor-unique USB commands, but I don't work with iPods and so don't know if such PC software exists for you.)

Have you successfully used all 160GB on this iPod for a while, and only noticed problems recently? Some history of events leading to this point may help to better understand likely causes - or you can just keep running HDDLLF and see what happens.

Sorry I can't suggest more to help you at the moment.

P.S. Thanks for your subsequent post, and I now see that you weren't missing, what I thought you were missing - as I said, I was starting from obsolete knowledge of an older version - my bad. That's what happens when I rush to reply before I go to a meeting, and don't do my research first! Sorry again about that. Hopefully other members will have more suggestions for you!

No sweat regarding the page change.

As for the topic of interest, thanks for your very informative reply. It confirmed my previous understanding. I had known most/all of the issues you mention, but had not articulated them fully and ultimately I had been unsure how strict the inability to reach through USB to the hardware. I had always assumed that it was pretty strict, but I always wondered what low level commands might be eventually supported. Then, in the course of my recent research, various things suggested perhaps there were a newer generation of tools that help provide some solution short of replacing the HD.

Ah well, its not that big a deal.

In the end, all I really need to do is mark all those blocks as used but I wanted some automated way to do it. I dont care if I have the full capacity of the drive, just that it doesn't fail trying to use the bad areas.

Anyway, best regards.

Thanks - that's a bit embarrassing for me


In that situation, what I would do is use either WinXP or earlier version to do a full format. In that OS, a full format (i.e. not a quick format) will read the whole disk (as well as write a new FAT etc.), and any unreadable blocks which are detected during the read of the whole device (assuming they don't cause the format to hang again), get their respective FAT clusters marked as faulty in the FAT and hence not used for storing files.

You could tell that this has been done by doing a dir afterwards, and you should see a message like "xxxk in bad blocks" or something similar - that tells you how many kB of unreadable blocks had their respective FAT clusters marked as bad.

I think there's a way to do something similar in Linux using the badblocks utility, if you prefer to research that instead of using an old Windows version.

That technique might be what you're looking for - but the inability to get the device to not use faulty blocks makes me concerned that the flash in that device might be on its last legs (as we say over here in the UK ). Make sure you have a backup of what's on there!

Hope that helps

Indeed, you just revealed the mechanism that most closely matches the observed behavior. Yeah, flash failing would explain it. It never occurred to me that such a thing would be that common, but based on your tone and phrasing I have a new understanding and I agree with your analysis. All the more reason to just semi-manually mark all that questionable space as used or something.

Based on the performance of the format, I am pretty sure one of my heads is crashed. There is a pretty clear rythm of fast block writes followed by very slow ones. I dont know the physical geometry of the device in question but I assume its multi-head.


Anyway, an inaccessible surface would potentially explain a lot of the strange behavior.

In any case, that they use flash for sparing, and that the flash lifetime (particularly when stressed) is not apparently designed for high use scenario. Prolly figure if its failing enough to burn up the flash it needs replacing anyway, but I am a die hard. Years ago, when I worked at Apple, I actually rescued one of the first 5 meg apple hard disks from a fire. It was literally a blob of plastic and ash mud. I took everything apart (cept the mech assembly) washed everything with a tooth brush and tri-clor and got the entire unit working again. After transferring the files, I was gifted the old unit and it became my personal hard drive at a time when very few had them. It continued to work for many years... Anyway I digress. Point being that I often band-aid stuff and often double or triple its lifetime. I was merely hoping for the same result here. This is the second time this unit has been near death, I will be really pleased if I can stabilize it with reduced capacity and get another year or two.

Your input is once again greatly appreciated.

Please keep choosing excellence for your days.

Best regards..

Pete McDonald

To the OP, if you're really interested in getting into it I would recommend opening the iPod and taking the drive out, then hooking it up directly to your computer via whatever adapter will be needed and running MHDD or similar. It should be possible to look up your iPod's model number and determine for sure what kind of drive is inside.

I would not expect there is any flash involved, in a 160GB unit.

_________________
You don't have to backup all of your files, just the ones you want to keep.

Hmmm.. well I was liking the explanation of failing flash. Without that functionality in the model, there are some anomalous aspects of the failure that I can not correlate. I am not sure whether this moves me back or whether your hedge leaves room for flash to still be the cause. What would they use if there were no flash? Either way, thanks for your input.

I don't have a zif cable, and one of the tenants of my philosophy is that I almost never spend money when attempting to re-gen a device particularly I am trying to avoid spending money that may not actually provide a solution. Still I guess I have enough IPODs these days maybe I can justify it.

In any case, thanks again for your suggestion. It is likely the only path to a comprehensive correction short of a real repair/replacement.

Best regards.

As usual, drc is correct, and my memory was wrong

Instead of relying on my (flaky) memory of iPods, thanks to Wikipedia, yours is apparently an iPod classic if it has 160GB, and not one of the flash-based later models which I was thinking of - see here for the discussions and list of models, and look for yours:

http://en.wikipedia.org/wiki/IPod


Just a duff internal hard disk is more likely, if there are specific problem addresses (the interface could be faulty if problems were random but not if, as you mentioned before, you have specific problem LBA regions).

My earlier comments about the limitations of any diagnosis or repair via USB still hold true, irrespective of whether the internal storage is a disk or flash.

As you can tell, I don't have an iPod classic to do this check (mine's a flash-based model, hence my mistake in assuming yours was), but no-one has mentioned checking the your disk's SMART data via USB yet. That's either because this isn't supported by the (Toshiba?) disk in an iPod classic, or just that no-one else has thought of that suggestion yet. Now knowing (thanks to drc) that yours likely has a disk and not flash, then reading the SMART data (or at least trying to, to see if its supported), would be my first attempt to gauge the health of the internal disk.

Or, as drc suggested, your other option is to open the iPod and deal with the bare hard disk itself...