How to change the inode size on an EXT3 partition?

Question

The setup:

For my dual-boot laptop, I have bought a large hard drive to use as external USB solution. I decided to use EXT3 as filesystem, thinking to use Ext2IFS to access the drive from Windows (as I already do with various other external devices).

The problem:

Linux is my primary choice as OS; as such, the drive was already 2/3rd full before I ever attempted to access it from Windows. It was only then I realized I made a severe mistake - I forgot to limit the inode size to 128. The default value used by the Linux distro was 256, which Ext2IFS cannot access.

At 1 TB, the drive is by far my largest storage, and at 2/3rd full would be awkward to backup.

The question:

Is it possible to change the inode size on an EXT3 partition (without losing the data)? I don't care if it takes a couple of hours.

---

Post Scriptum:

David Spillett perfectly answered the original question - "how to change the inode size on an EXT3 partition?".

The underlying question, however, was "how do I access an EXT3 partition from Windows after I created it with the Linux default values for inode size?".

The answer would be Ext2Fsd, which is an EXT3 driver for Windows that doesn't balk at large inode sizes. (It does not, however, support GUID Partition Tables (GPT), required for drives larger than 2 TB.)

I thought this might be of interest for the many people who look at this question.

Solution 1

You can't change it in place, as far as I know. You may be able to do it without finding another Tb drive to copy the data to while you rebuild the filesystem by a round-about method:

1. shrink the current filesystem as small as it will go and drop the length of the partition accordingly
2. add a second partition in the newly freed space
3. mount both, and move as much over to the new partition as you can
4. shrink the first partition again, move the new one down the disk and grow it to fill the drive and repeat step 3
5. you might need to repeat step 4 once or twice more depending on how full the original filesystem was to start with

You can do all the above manually with fdisk, resize2fs and related tools, or with parted which is available in most distribution's repositories and as a Live CD. gparted it probably the safest option by far unless you are very familiar with the manual tools already.

But major filesystem move/resize operations like these are the sort of thing I always take good backups before starting, because if anything goes wrong you could kill everything on the affected filesystem(s). So if you are healthily paranoid the above does not remove the need to find somewhere to copy the data too while you reformat/rearrange... Though if most of the data is replaceable, by re-downloading music/video content and such, you could backup the most important stuff and take a chance with the rest.

As an alternative to reformatting/rearranging the drive now you could run a small Linux VM (with vmware or vbox), attach the USB drive to that, and have it share the data to the host (Windows) OS via Samba. This is inefficient and less convenient, of course, but may well be efficient enough "for the time being" until you sort or more permanent solution like buying a new drive to reformat and move everything onto and it is certainly safer than massive filesystem operation on data that you do not have backed up. You do not need to allocate much resource to the VM, I'm guessing a server install of Ubuntu or a base install of Debian would happily run such a Samba share in 128Mb of RAM or less and would not need much more than a single Gb of disk space (in fact, it may only take a couple of hundred Mb, if that) on the host machine.

Solution 2

You can't change it, you have to recreate the filesystem from scratch.

From the man page for mke2fs:

-I inode-size
    Specify  the  size  of  each  inode  in  bytes.   mke2fs creates
    256-byte inodes by default.
    ...
    It is not possible to change this value
    after the filesystem is created.

Comments

[DevSolar]

+1. The shrink-move-shrinkagain scheme is a very nice suggestion; I'm not sure I could've come up with that one myself. Indeed most of the data would be replacable if need be, so I can get away with one or two hundred MB of backup instead of the whole block. Thanks!

[DevSolar]

mke2fs isn't capable of shrinking a partition either, but gparted can; that's why I suspected there could be some tool capable of changing the inode size too. But thanks for the advice!