19 Jan
2017
19 Jan
'17
7:53 p.m.
I has being avoiding to enter the eternal discussion about disk formats.
But I'm extremely interested to know the specific errors have encountered.
Thanks Wolfang, great info. Always thought the 128 was for windows based
servers/tms using a commercial EXT2 plugin that only supports 128,
interesting that some linux based servers can have this problem too.
Would be great to know the exact Servers, TMS or other systems that do not
recognize FAT32, NTFS or even EXT2 (yes they do exist), or any other
limitation relevant for operation and the kind of users now with dcpomatic.
And if known, what upgrade is needed (free software, hardware, new system)
I have absolutely no empathy to theaters that don't even care to update
software that is a few years old, or technicians doing crappy
installations. Most do a great work and don't deserve suffering outdated
workflows because of that few lazy ones.
I have a largely delayed article about diskless distribution, mainly for
festivals and the productions that mostly do festivals, so some unorthodox
tricks will be there, including non recommended disk formats that actually
wok. I'm comfortable sharing with whoever want to comment or collaborate
finishing it for a wider release. Nothing so especial, but I don't want
some random users interpreting that they can send whatever they want out
there.
Manuel AC
On Thu, Jan 19, 2017 at 1:52 PM, Wolfgang Woehl via DCPomatic <
dcpomatic(a)carlh.net> wrote:
--
http://akadcp.com/
https://www.facebook.com/akadcp
On 16 Jan 2017, at 12:44, Jim Dummett via
DCPomatic <dcpomatic(a)carlh.net>
wrote:
Hmm. Interesting. A good first step I guess might be to submit a patch
for gparted
to allow you to set the inode. Most people of course prefer a
GUI but I only know of command line methods to do it completely by the book
with 128 inode value.
A bit of context wrt inode size of 128 bytes; these couple of paragraphs
were written in runes in the year of 2013:
///
The default inode size for EXT2/3 filesystems changed years ago (from 128
to 256 bytes). The motivation was to be able to store extended attributes.
In Digital Cinema context noone should care, really, but there's a catch:
Systems with 2.4 series linux kernels won't be able to mount filesystems
with inode sizes > 128 bytes at all.
In linux history terms the 2.4 series is the middle ages. Noone sane
should be running kernels that old. Fact is there are some systems out
there which do.
These are abandoned legacy systems.
Their vendors don't care to upgrade them.
Their users are not eager to spend a couple of K's again.
So if you don't want to run into issues you'll want to use 128 bytes for
inode size, period.
Yes, this is 2013. Most userland FS tools won't even let you tweak the
setting. Its relevance died that far back. mkfs.ext2 and mkfs.ext3 - here
we come!
One thing these vendors are rather tight-lipped about:
Linux 2.4 series kernels carry a long list of vulnerabilities. These
systems are not at all safe or able to withstand even half-serious snooping
since a long time. If I were Fox or Warner or Sony I'd make sure these
boxes either get updated or blacklisted fast.
///
My theory and hope, or rather, game plan at the time was that userland
would increasingly ignore a setting from the stone ages and force those
systems out of the market.
I don’t have any numbers to check how that worked out.
Got a feeling, though, it just didn’t and the affected systems are still
out there somewhere. Waiting. Slowly filling their caves with bones of the
newborns they get fed with every now and then. Patiently preparing to grab
you by the throat :)
Wolfgang
_______________________________________________
DCPomatic mailing list
DCPomatic(a)carlh.net
http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic