New: journal_data mount option causes filesystem corruption with blocksize != 4096

http://bugzilla.kernel.org/show_bug.cgi?id=9692

           Summary: journal_data mount option causes filesystem corruption
                    with blocksize != 4096
           Product: File System
           Version: 2.5
     KernelVersion: 2.6.23.9
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: high
          Priority: P1
         Component: ext3
        AssignedTo: [email protected]
        ReportedBy: [email protected]

Most recent kernel where this bug did not occur: -
Older kernels have this problem too (I think I noticed this booting >= 2.6.21, definitely 2.6.22).

Distribution: Gentoo Linux x86
This bug seems to be hardware-independent (tested on three different machines which all use quite different drivers). If you need hardware information or any other log or configuration files, let me know please.

Problem Description:
When creating an ext3 filesystem with journal_data option and block sizes different than 4096 (tested: 1024, 2048) filesystem corruption will occur if certain operations are performed (see below).
Corruption will not occur if 4096 block size is used, or if any other block size is used together with journal_data_ordered or journal_data_writeback. No errors in dmesg.

Steps to reproduce:
I found this bug using an audio file tagger, so you need exfalso which is part of quodlibet (http://www.sacredchao.net/quodlibet/). No other file tagger I used produced this kind of problem. Still, this has to be a kernel problem, right??

1. Create ext3 file system:
mkfs.ext3 -O has_journal,dir_index -b 1024 /dev/sdd1 tune2fs -c 0 -i 0 -m 0 -o journal_data /dev/sdd1

tune2fs 1.40.3 (05-Dec-2007) (filtered)

Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal resize_inode dir_index filetype
sparse_super
Filesystem flags:         signed directory hash
Default mount options:    journal_data
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              126976
Block count:              1012060
Reserved block count:     0
Free blocks:              976865
Free inodes:              126965
First block:              1
Block size:               1024
Fragment size:            1024
Reserved GDT blocks:      256
Blocks per group:         8192
Fragments per group:      8192
Inodes per group:         1024
Inode blocks per group:   128
Last mount time:          n/a
Mount count:              0
Maximum mount count:      -1
Check interval:           0 (<none>)
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:       128
Journal inode:            8
Default directory hash:   tea
Journal backup:           inode blocks

2. Mount it and copy mp3,ogg,... files to it. This does not cause any file system corruption (which you can confirm by running fsck).

pmount /dev/sdd1:
/dev/sdd1 on /media/sdd1 type ext3 (rw,noexec,nosuid,nodev,errors=continue)

3. Use quodlibet/exfalso to change the id3 tags. Add tags to it if not present, or delete them if already present. This will lead to file system corruption.

brw-r----- 1 root disk 8, 49 /dev/sdd1

4. Unmount the volume.
pumount /dev/sdd1

5. Run fsck -fvD /dev/sdd1. It will complain about wrong i_size.

e2fsck 1.40.3 (05-Dec-2007)
Pass 1: Checking inodes, blocks, and sizes
Inode 47106, i_size is 5015509, should be 5017600. Fix<y>? yes Inode 47107, i_size is 4657736, should be 4661248. Fix<y>? yes Inode 47109, i_size is 11928555, should be 11931648. Fix<y>? yes

Inode 47111, i_size is 5698454, should be 5701632.  Fix<y>? yes
Inode 47112, i_size is 9384018, should be 9388032.  Fix<y>? yes
Inode 47114, i_size is 5679228, should be 5681152.  Fix<y>? yes
Inode 47115, i_size is 6107218, should be 6111232.  Fix<y>? yes
Inode 47117, i_size is 4354297, should be 4358144.  Fix<y>? yes
Inode 47118, i_size is 4512286, should be 4513792.  Fix<y>? yes
Inode 47120, i_size is 7010846, should be 7012352.  Fix<y>? yes

Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 3A: Optimizing directories
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/dev/sdd1: ***** FILE SYSTEM WAS MODIFIED *****

      28 inodes used (0.02%)
      14 non-contiguous inodes (50.0%)
         # of inodes with ind/dind/tind blocks: 15/15/0

123417 blocks used (12.19%)
0 bad blocks
0 large files

16 regular files
3 directories
0 character device files
0 block device files
0 fifos
0 links
0 symbolic links (0 fast symbolic links)
0 sockets
--------
19 files

Reproducible: Always.
No binary modules were loaded, clean boot from vanilla kernel. But of course, also happens with gentoo-sources and tuxonice-sources and nvidia binary loaded ;-).

Signature · 3 lines

Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

Quoted 18 lines · On Sat, 5 Jan 2008 09:52:15 -0800 (PST) [email protected] wrote:

http://bugzilla.kernel.org/show_bug.cgi?id=9692

           Summary: journal_data mount option causes filesystem corruption
                    with blocksize != 4096
           Product: File System
           Version: 2.5
     KernelVersion: 2.6.23.9
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: high
          Priority: P1
         Component: ext3
        AssignedTo: [email protected]
        ReportedBy: [email protected]

Quoted 3 lines

Most recent kernel where this bug did not occur: -
Older kernels have this problem too (I think I noticed this booting >= 2.6.21, definitely 2.6.22).

I'm getting the feeling that we should just disable data=journal. Make it use data=ordered mode instead. It isn't getting a lot of attention..