From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 1 01:52:29 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5545E737; Fri, 1 Mar 2013 01:52:29 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from flat.berklix.org (flat.berklix.org [83.236.223.115]) by mx1.freebsd.org (Postfix) with ESMTP id 7CB8BE7F; Fri, 1 Mar 2013 01:52:28 +0000 (UTC) Received: from mart.js.berklix.net (pD9FBE93D.dip.t-dialin.net [217.251.233.61]) (authenticated bits=128) by flat.berklix.org (8.14.5/8.14.5) with ESMTP id r210jnTm038059; Fri, 1 Mar 2013 01:45:50 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id r210jrr4085349; Fri, 1 Mar 2013 01:45:53 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.4/8.14.4) with ESMTP id r210j3IF038754; Fri, 1 Mar 2013 01:45:53 +0100 (CET) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201303010045.r210j3IF038754@fire.js.berklix.net> To: hackers@freebsd.org Subject: sbin/fsck_msdosfs does not handle media with 2K blocks From: "Julian H. Stacey" Organization: http://berklix.com BSD Linux Unix Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com/~jhs/cv/ Date: Fri, 01 Mar 2013 01:45:03 +0100 Sender: jhs@berklix.com Cc: Tom Rhodes , paulp@uts.amdahl.com, rnordier@freebsd.org, gdt@NetBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 01:52:29 -0000 Hi hackers@freebsd.org cc: gdt@NetBSD, paulp@uts.amdahl.com (< grep @ src/sbin/fsck_msdosfs/*.c) cc: rnordier@FreeBSD.org (< man newfs_msdos) cc: Tom Rhodes (< man 5 msdosfs> sbin/fsck_msdosfs (FreeBSD 9.1-RELEASE) fails on 2K block media, media in this case, an mp3 player: http://www.berklix.com/~jhs/txt/sigmatel/ sysctl kern.geom.debugflags=16 kern.geom.debugflags: 16 -> 16 /sbin/fsck_msdosfs /dev/da0s1 ** /dev/da0s1 could not read boot block (Invalid argument) devd.conf: "vendor" "0x066f"; "product" "0x8000"; "devclass" "0x00"; "devsubclass" "0x00"; "intclass" "0x08"; "intsubclass" "0x06"; "intprotocol" "0x50" ; "release" "0x1001"; /sys/dev/usb/usbdevs: vendor SIGMATEL 0x066f Sigmatel dd if=/dev/da0 bs=2k of=da0 # 242304+0 records 496238592 bytes dd if=/dev/da0s1 bs=2k of=da0s1 # 242256+0 records 496140288 bytes echo "2048 242304 * p" | dc # 496238592 echo "2048 242256 * p" | dc # 496140288 fdisk /dev/da0 cylinders=118 heads=64 sectors/track=32 (2048 blks/cyl) Media sector size is 2048 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 6 (0x06),(Primary DOS, 16 bit FAT (>= 32MB)) start 48, size 242256 (473 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 630/ head 7/ sector 48 ( I think this unit's FS got corrupted. Possibly as part of media error ? This unit (when not USB connected, but powered on battery as a player, flashed its LCD display on & off, (ame warning as to also indicate a low battery) whereas other units of same type with same battery powered up OK, & battery is OK, so player is probably also seeing a bad FS. ) I tried this: sysctl kern.geom.debugflags=16 dd if=/dev/da0s1 bs=2k of=image mdconfig -a -t vnode -f image /sbin/fsck_msdosfs -y /dev/md2 ** /dev/md2 ** Phase 1 - Read and Compare FATs ** Phase 2 - Check Cluster Chains ** Phase 3 - Checking Directories /audio has entries after end of directory Extend? yes /audio has entries after end of directory Extend? yes long filename record cluster start != 0 Invalid long filename entry for volume label Remove? yes ** Phase 4 - Checking for Lost Files 139 files, 60280 free (7535 clusters) ***** FILE SYSTEM WAS MODIFIED ***** ... Repeating fsck above, shows the same errors above ... newfs_msdos -F 16 -S 2048 /dev/md2 newfs_msdos: Cannot get number of sectors per track, Operation not supported newfs_msdos: Cannot get number of heads, Operation not supported newfs_msdos: trim 21 sectors to adjust to a multiple of 63 /dev/md2: 242192 sectors in 15137 FAT16 clusters (32768 bytes/cluster) BytesPerSec=2048 SecPerClust=16 ResSectors=1 FATs=2 RootDirEnts=512 Media=0xf0 FATsecs=15 SecPerTrack=63 Heads=16 HiddenSecs=0 HugeSectors=242235 /sbin/fsck_msdosfs -y /dev/md2 ** /dev/md2 ** Phase 1 - Read and Compare FATs ** Phase 2 - Check Cluster Chains ** Phase 3 - Checking Directories ** Phase 4 - Checking for Lost Files 1 files, 484384 free (15137 clusters) mount -t msdosfs /dev/md2 /mnt cp SETTINGS.DAT /mnt umount /mnt mdconfig -d -u 2 dd if=image bs=2k of=/dev/da0s1 dd: /dev/da0s1: Input/output error 80+0 records in 79+0 records out 161792 bytes transferred in 32.715037 secs (4945 bytes/sec) ... Remove & Reinsert & waited for devd & unmounted after auto-mount... Repeated dd & same error. ... Remove & Reinsert & wait for devd automount ls /usb/sigmatel ... it has the new empty FS with SETTINGS.DAT ... but still the LCD flashes fdisk -B /dev/da0 fdisk: /boot/mbr: length must be a multiple of sector size cat /boot/mbr /boot/mbr /boot/mbr /boot/mbr > /boot/mbr2k fdisk -B -b /boot/mbr2k /dev/da0 Should we write new partition table? [n] y ... still the LCD flashes fdisk -i /dev/da0 fdisk -u /dev/da0 ( Not Tried: newfs_msdos with -s 512 to see if the Sigmatel chipset will play it, but not much point as fdisk says 2K ... ) So it seems this particular unit has a problem (that other units of same manufacture here do not have). I can't think what else to try ? It seems I discovered a limitation in FreeBSD (while doing the above): We should hack various sources to [also?] allow R/W of 2K media blocks , eg inc. here: /usr/src/sbin/fsck_msdosfs/ dosfs.h: #define DOSBOOTBLOCKSIZE 512 boot.c: readboot(int dosfs, struct bootblock *boot) { u_char block[DOSBOOTBLOCKSIZE]; if (read(dosfs, block, sizeof block) != sizeof block) { perror("could not read boot block"); Who might best hack those sources ? Maybe someone since 1997 Wolfgang Solfrank & 1995 Martin Husemann be interested? Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Reply below not above, like a play script. Indent old text with "> ". Send plain text. No quoted-printable, HTML, base64, multipart/alternative.