Windows can't handle NTFS on external hard disks?
in [Chips]
|
Prev: WinDbg: Unable to get verifier list
Next: AMD accuses Nvidia of disabling multi-core CPU support in PhysX,to make GPU's look better
From: mike on 12 Jan 2010 19:45 Arno wrote: > In comp.sys.ibm.pc.hardware.storage mike <spamme0(a)go.com> wrote: >> Yousuf Khan wrote: >>> Yousuf Khan wrote: >>>> Mark Hobley wrote: >>>>> Have you changed something on the system? >>>>> Has the harware changed? >>>>> Has any software been updated? (Beware of automatic updates) >>>> Actually, the only change that I made to the system is that I added a >>>> second external USB HD to it. It had a previous USB HD already >>>> attached to it before, which is still attached to it, but then I >>>> picked up a second one right after Boxing Day. Come to think of it, >>>> the first crash occurred just a couple of days after that. >>>> >>>> I'm willing to entertain the possibility that this new external drive >>>> is somehow to blame, but I don't see why. It's just using a standard >>>> Microsoft USB Mass Storage driver, and so was the previous external >>>> drive. I don't think it could be due to power supply issues as I >>>> upgraded the system's power supply early last year to a high-capacity >>>> Zalman 650W unit. >>>> >>>> >>>> Yousuf Khan >>> I've added the comp.sys.ibm.pc.hardware.storage newsgroup too, since >>> it's looking like this is becoming storage-related. >>> >>> First, so to summarize again, I've now had 5 BSOD crashes on one of my >>> systems since Christmas. The only change to my system happens to be a >>> new external USB hard disk that I got after Christmas. The first crash >>> occurred only a few days after attaching this device, on Dec 30th. The >>> system previously had a similar external storage enclosure which has had >>> no problems. They were similar, however the older drive was a 500GB >>> formatted in FAT32, whereas the newer drive is a 1TB formatted in NTFS. >>> >>> Secondly, the most recent crash occurred right in the middle of a large >>> file transfer from one my internal drives to the new external drive. >>> >>> This is pretty strong circumstantial evidence that something about this >>> drive is causing the problem. But I've also been analysing the crash >>> dumps, and they all implicate either the OS kernel itself, NTOSKRNL, or >>> the HAL.DLL driver, or the NTFS.SYS driver. >>> >>> In fact the most recent BSOD was a Stop 0x24 (NTFS_FILE_SYSTEM) right on >>> the NTFS.SYS driver (see quote below): >>> >>>> BugCheck 24, {1902fe, f78beba0, f78be89c, b83fb504} >>>> >>>> Probably caused by : Ntfs.sys ( Ntfs!NtfsDeleteCcb+84 ) >>> So the question is, perhaps USB hard disks formatted to NTFS might not >>> respond fast enough to the system's liking, since NTFS usually goes on >>> internal hard disks. Is there some way to increase a timeout or anything >>> for this drive? >>> >>> I always wondered why Microsoft bothered to create a new ExFAT file >>> system, to replace FAT32, when NTFS was already around. This might be >>> the answer. >>> >>> Yousuf Khan > >> Don't know if any of this is relevant, but... >> I started having file transfer problems when I installed vista. >> Network file transfers to/from XP failed randomly, but only when the file >> being transferred exceeded ~4MB and was in the middle of a multi-file >> transfer. Also seemed to matter which end of the pipe initiated >> the transfer. >> I couldn't make a vista to vista file transfer fail. > >> I use totalcommander as my file manager. It has the option to use >> file transfer compatibility mode, whatever that is. Doesn't fail in >> that mode, so I quit looking for the problem. > >> I've had usb file transfer failures to external drives when using the >> front-mounted ports on my dell. >> Hubs are a no-no. > > I find this surprising. I have both used long USB cables > (5m) and USB hubs to transfer large volumes of data. > However that was with Linux, it is possible that Windows > vista / 7 has a very low resilience to USB errors. Linux > does up to 4 (I think) retries and bus reset on disk access > errors, whether it is (S)ATA or USB. If vista / 7 fails > the transfer directly after any error, that would explain > the ibserved behaviour. Long cables and USB hubs make > errors more likely. > >> If I look in device manager, I see more entries for root hubs >> than for controllers. Don't know exactly what this means, but >> sometimes, moving the usb drive to another port helps. > > That means that there are "virual hubs". > >> Bus-powered drives are problematic, but I expect your TB drive isn't. > > Again, depends. They have a tendency to cause more transfer > errors, but not to unusability, at least not with Linux. > >> Power supplies that come with external drives are problematic. >> Might be worth a look at the PS voltages with a scope under load. > > I agree. However I did the scope test with one that caused one > specific drive to have problems and I did see nothing with > a 10MHz 10mV/div (elCheapo, I know) scope. I also played around > a bit with one of these PSUs and it seems some have very little > stability margin. > >> There have been numerous complaints about recent generations of >> hard drives in the 1TB range. > > Oh? I have several Samsungs and WDs and no issues. I don't > remember reading more about these or other 1TB drives. Do > you have specifics? Don't know how you missed it. Back around September, the press was so bad on Seagate .11 series drives in the 1-1.5TB range that they were practically giving them away. They had a program for free data recovery if you sent in your permanently-locked-up drive. Not clear how many firmware updates they had. Seems that people were not satisfied that the firmware fix did anything other than throttle the performance. Interesting coincidence that they also changed the warranty from 5-years to, I think, three. I stayed away from that whole mess. > >> NTFS doesn't seem to matter on smaller drives where you can do a >> direct ntfs/fat32 comparison on the same hardware. > > So far the advantage I see for NTFS is extended attributes, > i.e. per user permissions. For a single-user machine and > for external drives this is rather irrelevant. Doesn't fat32 have a 4GB file size limit? Big problem if you store DVD images or large backup files on your external drive. > > Arno
From: Rod Speed on 12 Jan 2010 21:05 mike wrote: > Arno wrote: >> In comp.sys.ibm.pc.hardware.storage mike <spamme0(a)go.com> wrote: >>> Yousuf Khan wrote: >>>> Yousuf Khan wrote: >>>>> Mark Hobley wrote: >>>>>> Have you changed something on the system? >>>>>> Has the harware changed? >>>>>> Has any software been updated? (Beware of automatic updates) >>>>> Actually, the only change that I made to the system is that I >>>>> added a second external USB HD to it. It had a previous USB HD >>>>> already attached to it before, which is still attached to it, but >>>>> then I picked up a second one right after Boxing Day. Come to >>>>> think of it, the first crash occurred just a couple of days after >>>>> that. I'm willing to entertain the possibility that this new external >>>>> drive is somehow to blame, but I don't see why. It's just using a >>>>> standard Microsoft USB Mass Storage driver, and so was the >>>>> previous external drive. I don't think it could be due to power >>>>> supply issues as I upgraded the system's power supply early last >>>>> year to a high-capacity Zalman 650W unit. >>>>> >>>>> >>>>> Yousuf Khan >>>> I've added the comp.sys.ibm.pc.hardware.storage newsgroup too, >>>> since it's looking like this is becoming storage-related. >>>> >>>> First, so to summarize again, I've now had 5 BSOD crashes on one >>>> of my systems since Christmas. The only change to my system >>>> happens to be a new external USB hard disk that I got after >>>> Christmas. The first crash occurred only a few days after >>>> attaching this device, on Dec 30th. The system previously had a >>>> similar external storage enclosure which has had no problems. They >>>> were similar, however the older drive was a 500GB formatted in >>>> FAT32, whereas the newer drive is a 1TB formatted in NTFS. Secondly, the most recent crash occurred right in the >>>> middle of a >>>> large file transfer from one my internal drives to the new >>>> external drive. This is pretty strong circumstantial evidence that something about >>>> this drive is causing the problem. But I've also been analysing >>>> the crash dumps, and they all implicate either the OS kernel >>>> itself, NTOSKRNL, or the HAL.DLL driver, or the NTFS.SYS driver. >>>> >>>> In fact the most recent BSOD was a Stop 0x24 (NTFS_FILE_SYSTEM) >>>> right on the NTFS.SYS driver (see quote below): >>>> >>>>> BugCheck 24, {1902fe, f78beba0, f78be89c, b83fb504} >>>>> >>>>> Probably caused by : Ntfs.sys ( Ntfs!NtfsDeleteCcb+84 ) >>>> So the question is, perhaps USB hard disks formatted to NTFS might >>>> not respond fast enough to the system's liking, since NTFS usually >>>> goes on internal hard disks. Is there some way to increase a >>>> timeout or anything for this drive? >>>> >>>> I always wondered why Microsoft bothered to create a new ExFAT file >>>> system, to replace FAT32, when NTFS was already around. This might >>>> be the answer. >>>> >>>> Yousuf Khan >> >>> Don't know if any of this is relevant, but... >>> I started having file transfer problems when I installed vista. >>> Network file transfers to/from XP failed randomly, but only when >>> the file being transferred exceeded ~4MB and was in the middle of a >>> multi-file transfer. Also seemed to matter which end of the pipe >>> initiated the transfer. >>> I couldn't make a vista to vista file transfer fail. >> >>> I use totalcommander as my file manager. It has the option to use >>> file transfer compatibility mode, whatever that is. Doesn't fail in >>> that mode, so I quit looking for the problem. >> >>> I've had usb file transfer failures to external drives when using >>> the front-mounted ports on my dell. >>> Hubs are a no-no. >> >> I find this surprising. I have both used long USB cables >> (5m) and USB hubs to transfer large volumes of data. >> However that was with Linux, it is possible that Windows >> vista / 7 has a very low resilience to USB errors. Linux >> does up to 4 (I think) retries and bus reset on disk access >> errors, whether it is (S)ATA or USB. If vista / 7 fails >> the transfer directly after any error, that would explain >> the ibserved behaviour. Long cables and USB hubs make >> errors more likely. >> >>> If I look in device manager, I see more entries for root hubs >>> than for controllers. Don't know exactly what this means, but >>> sometimes, moving the usb drive to another port helps. >> >> That means that there are "virual hubs". >> >>> Bus-powered drives are problematic, but I expect your TB drive >>> isn't. >> >> Again, depends. They have a tendency to cause more transfer >> errors, but not to unusability, at least not with Linux. >> >>> Power supplies that come with external drives are problematic. >>> Might be worth a look at the PS voltages with a scope under load. >> >> I agree. However I did the scope test with one that caused one >> specific drive to have problems and I did see nothing with >> a 10MHz 10mV/div (elCheapo, I know) scope. I also played around >> a bit with one of these PSUs and it seems some have very little >> stability margin. >> >>> There have been numerous complaints about recent generations of >>> hard drives in the 1TB range. >> >> Oh? I have several Samsungs and WDs and no issues. I don't >> remember reading more about these or other 1TB drives. Do >> you have specifics? > > Don't know how you missed it. Back around September, > the press was so bad on Seagate .11 series drives in the 1-1.5TB range > that they were practically giving them away. They had a program > for free data recovery if you sent in your permanently-locked-up > drive. Not clear how many > firmware updates they had. Seems that people were not satisfied > that the firmware fix did anything other than throttle the > performance. Interesting coincidence that they also changed the > warranty from 5-years to, I think, three. > I stayed away from that whole mess. >> >>> NTFS doesn't seem to matter on smaller drives where you can do a >>> direct ntfs/fat32 comparison on the same hardware. >> >> So far the advantage I see for NTFS is extended attributes, >> i.e. per user permissions. For a single-user machine and >> for external drives this is rather irrelevant. > Doesn't fat32 have a 4GB file size limit? Yes. > Big problem if you store DVD images And files created on a PVR etc. > or large backup files on your external drive. Those arent generally a problem, because the backup apps all allow for that limitation.
From: mike on 12 Jan 2010 22:17 Rod Speed wrote: > mike wrote: >> Arno wrote: >>> In comp.sys.ibm.pc.hardware.storage mike <spamme0(a)go.com> wrote: >>>> Yousuf Khan wrote: >>>>> Yousuf Khan wrote: >>>>>> Mark Hobley wrote: >>>>>>> Have you changed something on the system? >>>>>>> Has the harware changed? >>>>>>> Has any software been updated? (Beware of automatic updates) >>>>>> Actually, the only change that I made to the system is that I >>>>>> added a second external USB HD to it. It had a previous USB HD >>>>>> already attached to it before, which is still attached to it, but >>>>>> then I picked up a second one right after Boxing Day. Come to >>>>>> think of it, the first crash occurred just a couple of days after >>>>>> that. I'm willing to entertain the possibility that this new external >>>>>> drive is somehow to blame, but I don't see why. It's just using a >>>>>> standard Microsoft USB Mass Storage driver, and so was the >>>>>> previous external drive. I don't think it could be due to power >>>>>> supply issues as I upgraded the system's power supply early last >>>>>> year to a high-capacity Zalman 650W unit. >>>>>> >>>>>> >>>>>> Yousuf Khan >>>>> I've added the comp.sys.ibm.pc.hardware.storage newsgroup too, >>>>> since it's looking like this is becoming storage-related. >>>>> >>>>> First, so to summarize again, I've now had 5 BSOD crashes on one >>>>> of my systems since Christmas. The only change to my system >>>>> happens to be a new external USB hard disk that I got after >>>>> Christmas. The first crash occurred only a few days after >>>>> attaching this device, on Dec 30th. The system previously had a >>>>> similar external storage enclosure which has had no problems. They >>>>> were similar, however the older drive was a 500GB formatted in >>>>> FAT32, whereas the newer drive is a 1TB formatted in NTFS. Secondly, the most recent crash occurred right in the >>>>> middle of a >>>>> large file transfer from one my internal drives to the new >>>>> external drive. This is pretty strong circumstantial evidence that something about >>>>> this drive is causing the problem. But I've also been analysing >>>>> the crash dumps, and they all implicate either the OS kernel >>>>> itself, NTOSKRNL, or the HAL.DLL driver, or the NTFS.SYS driver. >>>>> >>>>> In fact the most recent BSOD was a Stop 0x24 (NTFS_FILE_SYSTEM) >>>>> right on the NTFS.SYS driver (see quote below): >>>>> >>>>>> BugCheck 24, {1902fe, f78beba0, f78be89c, b83fb504} >>>>>> >>>>>> Probably caused by : Ntfs.sys ( Ntfs!NtfsDeleteCcb+84 ) >>>>> So the question is, perhaps USB hard disks formatted to NTFS might >>>>> not respond fast enough to the system's liking, since NTFS usually >>>>> goes on internal hard disks. Is there some way to increase a >>>>> timeout or anything for this drive? >>>>> >>>>> I always wondered why Microsoft bothered to create a new ExFAT file >>>>> system, to replace FAT32, when NTFS was already around. This might >>>>> be the answer. >>>>> >>>>> Yousuf Khan >>>> Don't know if any of this is relevant, but... >>>> I started having file transfer problems when I installed vista. >>>> Network file transfers to/from XP failed randomly, but only when >>>> the file being transferred exceeded ~4MB and was in the middle of a >>>> multi-file transfer. Also seemed to matter which end of the pipe >>>> initiated the transfer. >>>> I couldn't make a vista to vista file transfer fail. >>>> I use totalcommander as my file manager. It has the option to use >>>> file transfer compatibility mode, whatever that is. Doesn't fail in >>>> that mode, so I quit looking for the problem. >>>> I've had usb file transfer failures to external drives when using >>>> the front-mounted ports on my dell. >>>> Hubs are a no-no. >>> I find this surprising. I have both used long USB cables >>> (5m) and USB hubs to transfer large volumes of data. >>> However that was with Linux, it is possible that Windows >>> vista / 7 has a very low resilience to USB errors. Linux >>> does up to 4 (I think) retries and bus reset on disk access >>> errors, whether it is (S)ATA or USB. If vista / 7 fails >>> the transfer directly after any error, that would explain >>> the ibserved behaviour. Long cables and USB hubs make >>> errors more likely. >>> >>>> If I look in device manager, I see more entries for root hubs >>>> than for controllers. Don't know exactly what this means, but >>>> sometimes, moving the usb drive to another port helps. >>> That means that there are "virual hubs". >>> >>>> Bus-powered drives are problematic, but I expect your TB drive >>>> isn't. >>> Again, depends. They have a tendency to cause more transfer >>> errors, but not to unusability, at least not with Linux. >>> >>>> Power supplies that come with external drives are problematic. >>>> Might be worth a look at the PS voltages with a scope under load. >>> I agree. However I did the scope test with one that caused one >>> specific drive to have problems and I did see nothing with >>> a 10MHz 10mV/div (elCheapo, I know) scope. I also played around >>> a bit with one of these PSUs and it seems some have very little >>> stability margin. >>> >>>> There have been numerous complaints about recent generations of >>>> hard drives in the 1TB range. >>> Oh? I have several Samsungs and WDs and no issues. I don't >>> remember reading more about these or other 1TB drives. Do >>> you have specifics? >> Don't know how you missed it. Back around September, >> the press was so bad on Seagate .11 series drives in the 1-1.5TB range >> that they were practically giving them away. They had a program >> for free data recovery if you sent in your permanently-locked-up >> drive. Not clear how many >> firmware updates they had. Seems that people were not satisfied >> that the firmware fix did anything other than throttle the >> performance. Interesting coincidence that they also changed the >> warranty from 5-years to, I think, three. >> I stayed away from that whole mess. >>>> NTFS doesn't seem to matter on smaller drives where you can do a >>>> direct ntfs/fat32 comparison on the same hardware. >>> So far the advantage I see for NTFS is extended attributes, >>> i.e. per user permissions. For a single-user machine and >>> for external drives this is rather irrelevant. > >> Doesn't fat32 have a 4GB file size limit? > > Yes. > >> Big problem if you store DVD images > > And files created on a PVR etc. > >> or large backup files on your external drive. > > Those arent generally a problem, because the backup apps all allow for that limitation. > > Yes, but if you made the backup to an ntfs drive and tried to copy it to the external drive, you have a problem. Allowing for a limitation works great if you know about that limitation beforehand and plan for it.
From: Robert Myers on 12 Jan 2010 22:59 On Jan 12, 10:52 am, Yousuf Khan <bbb...(a)spammenot.yahoo.com> wrote: > So the question is, perhaps USB hard disks formatted to NTFS might not > respond fast enough to the system's liking, since NTFS usually goes on > internal hard disks. Is there some way to increase a timeout or anything > for this drive? > > I always wondered why Microsoft bothered to create a new ExFAT file > system, to replace FAT32, when NTFS was already around. This might be > the answer. I have two huge NTFS-formatted USB drives running under Windows, but Vista, not XP. Never had a BSOD other than due to a video driver, now fixed. Robert.
From: Arno on 12 Jan 2010 23:13
In comp.sys.ibm.pc.hardware.storage mike <spamme0(a)go.com> wrote: > Arno wrote: [...] >>> There have been numerous complaints about recent generations of >>> hard drives in the 1TB range. >> >> Oh? I have several Samsungs and WDs and no issues. I don't >> remember reading more about these or other 1TB drives. Do >> you have specifics? > Don't know how you missed it. Back around September, > the press was so bad on Seagate .11 series drives in the 1-1.5TB range > that they were practically giving them away. They had a program > for free data recovery if you sent in your permanently-locked-up drive. Ah, that. But that was a firmware issue and well understood, not bad drive quality. > Not clear how many > firmware updates they had. Seems that people were not satisfied > that the firmware fix did anything other than throttle the performance. > Interesting coincidence that they also changed the warranty from 5-years > to, I think, three. > I stayed away from that whole mess. Well, yes, Seagate currently is the one to tay away from. >> >>> NTFS doesn't seem to matter on smaller drives where you can do a >>> direct ntfs/fat32 comparison on the same hardware. >> >> So far the advantage I see for NTFS is extended attributes, >> i.e. per user permissions. For a single-user machine and >> for external drives this is rather irrelevant. > Doesn't fat32 have a 4GB file size limit? Big problem if > you store DVD images or large backup files on your external drive. FAT32 has this limit, but a lot of software can work around it. Or use Linux for backups and images in the first place. That is what I do, the substandard MS trash is restriced to things that will only work there with me. Mostly games. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno(a)wagner.name GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans |