Tread lightly on the things of earth

Took me a long round of Googling to solve the following Linux/NetBSD problem, so I’m dumping my findings here to shorten the search for anyone else for whom this problem arises. For anyone else, this will be as dry as sawdust. ;-)

PROBLEM:
I triple-boot my old 450MHz Pentium III box at home among my current three favorite free OSs, Gentoo 2005.0, Ubuntu 5.04 Hoary, and NetBSD 2.0.2. I like ‘em all; each one has strengths and shortcomings, and I’m learning to maximize each one’s usefulness.

I keep the Linux partitions formatted as ext2 instead of newer journaled filesystems like ext3 or reiserfs so they’re mountable in NetBSD (whose native filesystem is FFS but that can read/write ext2). I assess from two years’ moderate-but-flawless use on another box that NetBSD’s read/write support for ext2 filesystems is robust enough to trust.

On this PIII box I particularly want to mount one huge ext2 partition (230GB) as /home when booted into any of Gentoo, Ubuntu, or NetBSD.

But suddenly I find NetBSD 2.0.2 can’t mount at least a couple of my ext2 partitions after I’ve been running Gentoo or Ubuntu for several days, but it can mount a third one. What’s different between the unmountable (hda1, hda4) and mountable partitions (hdb3)?

SOLUTION:

Short answer —

Linux (either the 2.6.x kernel or the system’s periodic fsck) is setting the large_file flag on ext2/ext3 partitions when it finds a 4GB+ file, and NetBSD’s ext2fs driver can’t mount the partition then. Details below on clearing an ext2/ext3 partition’s large_file flag, whereupon NetBSD can mount it read-write again.

Long answer —

Here’s the message bash in NetBSD reports when I tried to mount one of the problem partitions:

# mount -t ext2fs /dev/wd0h /home
mount_ext2fs: /dev/wd0h on /home: Read-only file system

But the partition isn’t mounted, not even read-only.

Booting back into Gentoo to use Linux e2fsprogs — specifically, dumpe2fs 1.35 (28-Feb-2004) — I see the following:

Gentoo’s root (NetBSD’s read-only /mnt/gentoo):
$ sudo dumpe2fs /dev/hda1 | grep features
Filesystem features: has_journal filetype needs_recovery sparse_super

Ubuntu’s root (NetBSD’s read-only /mnt/ubuntu):
$ sudo dumpe2fs /dev/hda2 | grep features
Filesystem features: has_journal filetype needs_recovery sparse_super

Gentoo/Ubuntu shared read-write /boot:
$ sudo dumpe2fs /dev/hda3 | grep features
Filesystem features: dir_index filetype sparse_super

Gentoo/Ubuntu/NetBSD shared read-write /home:
$ sudo dumpe2fs /dev/hda4 | grep features
Filesystem features: dir_index filetype sparse_super large_file

Gentoo/Ubuntu/NetBSD shared read-write /mnt/backup:
$ sudo dumpe2fs /dev/hdb3 | grep features
Filesystem features: filetype sparse_super

Much Googling later I think the dir_index flag is at least part of the problem. [Turns out, almost certainly not.] Obviously the sparse_super flag isn’t a problem, as hdb3 mounts in NetBSD. I’ll test to see if large_file is part of the problem, too [yes, it is; hda4 won’t mount in NetBSD even after removing dir_index].

Success: Removed both dir_index and large_file flags from ext2 filesystems according to instructions below, and now they’re mountable again in NetBSD! [But turning off dir_index probably wasn’t necessary; see below.]

[Running fsck.ext3 on hda1 and hda2 cleared the needs_recovery flag as expected.]

Now that I’ve solved the problem, how can I ensure that the dir_index and/or large_file flags aren’t turned back on for these ext2 filesystems while running under Gentoo (kernel 2.6.11) or Ubuntu Hoary (kernel 2.6.10)? I’m not sure what set them in the first place — is the Linux periodic ext2 fsck doing it?

---

How to turn off the dir_index flag on an ext2/ext3 filesystem

N. Charonitakis provides the necessary clue:

o Fresh installations of Red Hat Linux 8.0.92 will enable the experimental HTree feature on new ext3 filesystems.

The HTree feature makes file creation, deletion, and lookup faster. On filesystems that have HTree enabled, these file operations should not get significantly slower as the directory grows in size. …

You can remove the HTree indexing feature from a filesystem by issuing the following command:

tune2fs -O ^dir_index /dev/<filesystemdevice>

I observe dir_index can be turned back on with

# tune2fs -O +dir_index /dev/<filesystemdevice>

You can then remove the indices from the directories by issuing the following command:

e2fsck -f -D -p /dev/<filesystemdevice>

where

• “-f” is “force” the check even if the filesystem is marked clean
• “-D” is “optimize directories in filesystem …”
• “-p” is “automatically repair (‘preen’) the file system without any questions

Later: Hmmm, is the dir_index flag actually part of the problem in NetBSD?

Verified: No, it isn’t. After turning dir_index back on in Gentoo for /dev/hda3, I can still mount it in NetBSD. Therefore large_file is the sole culprit in preventing mounting an ext2 partition in NetBSD.

(Even so, I turned dir_index back on only for Gentoo’s and Ubuntu’s root filesystems, leaving it off elsewhere in case there’s a hidden drawback to its presence in NetBSD that I haven’t discovered.)

---

How to turn off the large_file flag on an ext2/ext3 filesystem

Alexander Viro provides the necessary clue:

I’ve got a large ext2 partition for sharing data with Linux. But several days ago I created a big file (>4 GB) in Linux and I can’t mount the partition anymore under FreeBSD — even if I delete the big file. I’m still getting this message:

mount_ext2: /dev/ad0s4: Invalid argument

Is there anything I can do? Reformat the partition? Does FreeBSD support large files on ext2 partitions?

You can use Linux debugfs (not FreeBSD one — you want a version that understands ext2, not UFS).

# debugfs -w <device> <<EOF
> feature -large_file
> dirty
> close
> quit
> EOF

As I do this in Gentoo, I observe the response from debugfs is

debugfs 1.37 (21-Mar-2005)
debugfs: Filesystem features: filetype sparse_super
#

Alexander continues:

followed by

# fsck.ext2 <device>

(the last one to make sure that you really don’t have large files sitting around; if some are still there fsck will set the ‘large_file’ flag back).

I see this response during the fsck:

—> “Filesystem contains large files, but lacks LARGE_FILE flag in superblock. Fix<y>?”

I said “n”.

My question is
Will the LARGE_FILE flag stay unset?

I see Andreas has answered this question:

So, I started poking around and found that some of my ext3 filesystems have the “large_file” feature flag set on them, and others do not. I cannot find a manpage for mke2fs anywhere that explains how to set this flag, either at creation time or afterwards. When I try something like “mke2fs -j -O large_file <dev>” mke2fs complains that it doesn’t understand the argument. Attempts to create ext3 filesystems using a modern debian-based (2.4.18) rescue CD also failed to set the large_file flag.

So, I guess my question is, in what version of mke2fs was support for large files implemented, and how do you enable it, if it’s not the default behavior?

That flag is set when a large file is created on the filesystem, and is not a feature you “activate” per se. Either your kernel “gets it” or it doesn’t.

I simply deleted the ~8GB tarball that was triggering the large_file flag. It was a long out-of-date backup; if I’d needed to keep it I suppose I’d have put it on a partition that doesn’t need mounting in NetBSD.