From: Stefan Seyfried <stefan.seyfried@googlemail.com>
To: Willy Tarreau <w@1wt.eu>
Cc: linux-kernel@vger.kernel.org, Stefan Seyfried <seife@sphairon.com>
Subject: Re: [PATCH 2.4] FAT: do not continue in fat_get_block if bmap fails
Date: Wed, 3 Feb 2010 10:14:49 +0100 [thread overview]
Message-ID: <20100203101449.2090aa57@strolchi> (raw)
In-Reply-To: <20100202220631.GA16098@1wt.eu>
Hi Willy,
On Tue, 2 Feb 2010 23:06:31 +0100
Willy Tarreau <w@1wt.eu> wrote:
> Hello Stefan,
>
> On Tue, Feb 02, 2010 at 02:00:35PM +0100, Stefan Seyfried wrote:
> > From: Stefan Seyfried <seife@sphairon.com>
> >
> > There is no use in continuing the write operation after fat_bmap() fails.
> > (This successfully killed a VFAT FS for me).
> > The corresponding code in 2.6 does return here as well, AFAICT.
>
> OK then that's fine, I'm merging it.
I'd like to add that I am not a filesystem expert at all, so if
somebody wants to suggest a better return code, I'm all for that.
And the dosfs code in 2.6 is substantially different, thus the "AFAICT"
above ;)
Anyway, continuing at that place (when phys == 0) is definitely
wrong, since writing to block 0 later on will kill the filesystem 100%.
I triggered this with a corrumpted file, which an application wanted to
modify, dosfsck had this to say about the file system:
strolchi:~ # dosfsck -nv /dev/sdb1
dosfsck 2.11 (12 Mar 2005)
dosfsck 2.11, 12 Mar 2005, FAT32, LFN
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID "MSDOS5.0"
Media byte 0xf8 (hard disk)
512 bytes per logical sector
16384 bytes per cluster
1 reserved sector
First FAT starts at byte 512 (sector 1)
2 FATs, 16 bit entries
124928 bytes per FAT (= 244 sectors)
Root directory starts at byte 250368 (sector 489)
512 root directory entries
Data area starts at byte 266752 (sector 521)
62283 data clusters (1020444672 bytes)
63 sectors/track, 32 heads
247 hidden sectors
1993577 sectors total
/test/test.db
File size is 188928 bytes, cluster chain length is 163840 bytes.
Truncating file to 163840 bytes.
Checking for unused clusters.
Reclaimed 2 unused clusters (32768 bytes).
Leaving file system unchanged.
/dev/sdb1: 201 files, 51608/62283 clusters
Thanks for merging and taking care of the "old lady" 2.4 ;)
Stefan
--
Stefan Seyfried
"Any ideas, John?"
"Well, surrounding them's out."
prev parent reply other threads:[~2010-02-03 9:15 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-02 13:00 [PATCH 2.4] FAT: do not continue in fat_get_block if bmap fails Stefan Seyfried
2010-02-02 22:06 ` Willy Tarreau
2010-02-03 9:14 ` Stefan Seyfried [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100203101449.2090aa57@strolchi \
--to=stefan.seyfried@googlemail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=seife@sphairon.com \
--cc=w@1wt.eu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox