On Sun, Sep 7, 2008 at 4:44 PM, Kenneth Porter shiva@sewingwitch.com wrote:
I'm backing up to a NTFS partition on an external USB drive with dump. I'm seeing failures in /var/log/messages reading sector 0xFFFFFFF that cause the verify pass to fail. Are there any known problems in the USB driver?
Kernel via uname -a:
Linux segw2.mpa.lan 2.6.18-92.1.6.el5 #1 SMP Wed Jun 25 13:49:24 EDT 2008 i686 i686 i386 GNU/Linux
Message reported. (Note the number 268435455, which is 0xFFFFFFF, and occurs every time I see this happen.
You are backing up to NTFS on Linux?
The NTFS file system specification is a trade secret last I checked..
Anytime I see an error where the number is binary all ones I suspect a magic number... and worry.
How was the disk partitioned? How was this partition formatted? Was the filesystem converted from old to new ntfs format?
http://technet.microsoft.com/en-us/library/cc781134.aspx
--On Monday, September 08, 2008 7:30 AM -0700 NiftyClusters Mitch niftycluster@niftyegg.com wrote:
You are backing up to NTFS on Linux?
The NTFS file system specification is a trade secret last I checked..
Anytime I see an error where the number is binary all ones I suspect a magic number... and worry.
How was the disk partitioned? How was this partition formatted? Was the filesystem converted from old to new ntfs format?
It's actually 3 drives that I rotate, and I've confirmed seeing this on two of them, and those two are different brands and sizes. The all-ones sector number indeed worried me. But the problem is reported below the filesystem level, from a raw sector read, so I'm inclined not to blame the filesystem here. Note how the log messages look like they're coming from the SCSI emulation layer.
BTW, the filesystem is actually the ntfs-3g FUSE-based system, which I've installed from the RPMForge repository.
Just for grins, I may go ahead and reformat to ext3 and try again, but the only thing I see that changing is the access pattern, which might hide the underlying problem.
-
Kenneth Porter -
NiftyClusters Mitch