All of lore.kernel.org
 help / color / mirror / Atom feed
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."

      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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.