128-byte inodes cannot handle dates beyond 2038 and are deprecated

[Leo Enticknap]

For the first time since upgrading Ubuntu from 20.04 LTS to 22.04 LTS, I got this error message when formatting a drive to put a DCP on. The actual command I used was:

mke2fs -t ext3 -I 128 -L "DCP" /dev/sdd

It then proceeded to format the volume, and so I presume that it actually did so with 128-byte inodes, that this message was purely informational, and that I have a drive that is partitioned and formatted per the ISDCF specs for a DCP distribution drive. But this leads me to wonder if we could have problems further down the line, especially if future versions of mke2fs that appear before 2038 won't allow you to format a drive that way.

The version of mke2fs is 1.46.5.

I should try formatting a drive without the -I 128 tag and seeing if the common server models will read it anyways; if they won't, either we will have to maintain older versions of the formatting utility, or this could be a problem going forward.

[John Thomas]

Interesting. I've been using a VM running Parted Magic with no warnings on this:

parted -s /dev/sdd mklabel msdos
parted -s -a optimal /dev/sdd mkpart primary 0% 100%
mkfs -t ext3 -I 128 -m 0 /dev/sdd1

[Carsten Kurz]

DCI servers have no trouble with larger inode sizes. It was some older TMS's running windows + and older versions of ext2/3 drivers who couldn't handle non-128 byte inode sizes. Neither 2038 nor inode size>128 should become a real problem for us.

[Leo Enticknap]

Thanks. The freebie ext2/3 drivers that were widely used with Windows 7 don't work with 10 or 11. The only one that will, reliably and stable, that I know of, is the Paragon Linux filesystem reader, which we pre-install on all our Windows-based GDC TMS builds. At $20, it costs almost nothing anyways.

Was the ISDCF recommendation for an inode size of 128 purely because of these freeware Windows ext2/3 readers? If so, I would suggest removing it from the formal spec, as there are no actual DCP servers out there that are Windows-based.

[Marcel Birgelen]

Thanks. The freebie ext2/3 drivers that were widely used with Windows 7 don't work with 10 or 11. The only one that will, reliably and stable, that I know of, is the Paragon Linux filesystem reader, which we pre-install on all our Windows-based GDC TMS builds. At $20, it costs almost nothing anyways.

You should also be able to mount ext* partitions in Windows using WSL 2, which is also free.

[Leo Enticknap]

I haven't tried this methods, but there appear to be two issues.

1 - You have to install the Windows Subsystem for Linux component, which is not installed with Windows by default. This is not a problem when creating a system image for a TMS, but potentially would be for an average-skilled end user trying to do this on a typical PC from scratch.

2 - You have to enter command lines into a terminal window to enable Windows to see the drive. The advantage with the Paragon app is that a theater manager can simply latch a CRU cartridge into the TMS, and the computer will mount it for the GDC software to see, without him or her having to do anything else.

Will certainly experiment with this when I get a moment, though.

[Marcel Birgelen]

The WSL route definitly is a power-user option. But it's a pretty powerful option. It's free, so it's also free from license hassles. WSL can be deployed on almost every recent Windows machine and it also allows for easy scripting. I've never benchmarked it against native Linux nor the Paragon solution, but it seems to be pretty performant also.

[Frank Cox]

I really don't know anything about how MS Windows works but if you're setting this up for Joseph J. Schmoe wouldn't it be possible to script the volume mounting process so he doesn't have to actually type anything into the scary terminal?

"Insert the drive and click this icon" shouldn't be too difficult for any end user to manage. (Famous last words.)

[Marcel Birgelen]

Yeah, a simple PowerShell script should be able to do that.

Microsoft's relationship with Linux has been a strange one over the years. First they avoided it like the pest, nowadays not only most of their Azure stuff seems to be powered by it, they even start to integrate it into Windows. Unfortunately, with Microsoft you never know if that's actually a good thing or not.

[Jim Cassedy]

"128-byte inodes cannot handle dates beyond 2038"

... by 2038, it's not going to be my problem, so I'm not going to loose any sleep over this.

[John Thomas]

Given the option between drives being compatible with legacy software still used here and there in 2022 and drives being compatible with dates beyond 2038, I'd go with the former and enforce the inode size 128. For now.

[Marcel Birgelen]

You're all contributing towards the 2038-apocalypse aka the Epochcalypse.

[Carsten Kurz]

We alread had issues with some KDM/certificates extenden post-2038. Some servers deny playout when e.g. signing cert validity period used for a KDM extend beyond 2038.

[Ian Freer]

... as there are no actual DCP servers out there that are Windows-based.

Except Qube.