Skip to contentSkip to conversation

2.4.0-prerelease & 2048-byte FAT sectors

DISCUSSION Desert Dragon 3 participants 3 messages Jan 1, 2001 – Jan 2, 2001

lore
Share & tools
lore
#0 lore raw

Just installed 2.4.0-prerelease, and it looks like FAT filesystems on hardware 2048-byte sectors are still not working.

Are there any plans to fix this, or should I consider such devices obsolete? I'm keeping 2.2.17 around and rebooting every time I have to access my MO drives -- rather inconvenient.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

#1 lore raw
Quoted 4 lines

Just installed 2.4.0-prerelease, and it looks like FAT filesystems on hardware 2048-byte sectors are still not working.
Are there any plans to fix this, or should I consider

Jens was fixing it for CD-ROM devices. I dont know if anyone was fixing for M/O devices currently

Quoted 1 line

such devices obsolete? I'm keeping 2.2.17 around and

Far from obsolete - its a bug.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

#2 lore raw
Quoted 11 lines · Alan Cox
Quoted 4 lines

Just installed 2.4.0-prerelease, and it looks like FAT filesystems on hardware 2048-byte sectors are still not working.
Are there any plans to fix this, or should I consider

Jens was fixing it for CD-ROM devices. I dont know if anyone was fixing for M/O devices currently

Quoted 1 line

such devices obsolete? I'm keeping 2.2.17 around and

Far from obsolete - its a bug.

This patch works good enough for me to get at the data on my MOs. Buyers beware! I'm completely ignorant to fs issues, so the implementation is not only dog slow but very probably also buggy. Anyway, it works for me, and it should be better than the current oops on read(). Maybe Al can have a quick look at it?

I also disabled mmap for large hw-block devices because the current implementation yields incorrect results.

Regards,

Daniel.

--[snip]--

fat/cvf.c renamed from fat/cvf.c.vanilla +4 -1
@@ -51,6 +51,9 @@
 	const char *buf,
 	size_t count,
 	loff_t *ppos);
+ssize_t bigblock_fat_file_read(struct file *filp, char *buf, size_t count,
+                               loff_t *ppos);
+
 
 struct cvf_format default_cvf = {
 	0,	/* version - who cares? */	
@@ -92,7 +95,7 @@
 	default_fat_access,
 	NULL,
 	default_fat_bmap,
-	NULL,
+	bigblock_fat_file_read,
 	default_fat_file_write,
 	NULL,
 	NULL
fat/file.c renamed from fat/file.c.vanilla +51 -0

63 lines not on this page · raw message

fat/inode.c renamed from fat/inode.c.vanilla +3 -0
@@ -820,6 +820,9 @@
 		inode->i_size = CF_LE_L(de->size);
 	        inode->i_op = &fat_file_inode_operations;
 	        inode->i_fop = &fat_file_operations;
+		/* FIXME: mmap is broken with large hwblocks! [dk] */
+		if (sb->s_blocksize > 512)
+			inode->i_fop->mmap = NULL;
 		inode->i_mapping->a_ops = &fat_aops;
 		MSDOS_I(inode)->mmu_private = inode->i_size;
 	}

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/