Mailinglist Archive: opensuse (626 mails)

< Previous Next >
[opensuse] Re: wrong topic: Re: Hard division inode/data is an anachronism
On 11/11/18 11:21 PM, L A Walsh wrote:

So sorry, I mentioned 'inodes', I should have said 'meta-data'.

Could you please clarify how that is different?

I do understand that an i-node *can also* carries allocation information.


In both the xfs and ntfs cases the meta-info could be containined in a space
roughly equivalent to the inode (ignoring MS's putting them all together in
a control block).

MS does have a tendency to use different names for familiar concepts.

And, on the other hand, the UNIX/Linux/BSD side calls it an 'i-node' whether it
is on disk (possibly in compressed form) or in memory (possibly in uncompressed
form with additional links & pointers).

There's a trope in SF/world-building: "Call a rabbit a Smerp".
It's a exhibition of the "We're in space, so regular old Earth flora and fauna
names just won't do.". That the Smerp is a vegetation with big, radar-like ears
to sense approaching predators is beside the point ...

"We're in MS-land so the regular old <strike>Earth</strike> CompSci
<strike>flora</strike> structures and <strike>fauna</strike> names just won't
do".

if you are going to call an 'inode' a 'control block' then you better illustrate
the relevance of the differences for all us Linux-weenies who have never drilled
down on MS-internals.


Now, (vs. 1980) we have xattrs that also include other meta data including
privileges and permission controls.

Yes, and we also have some file systems specifics, constraints or attributes
determined at FSCK time, perhaps.

The "i-" is for "Information".
Yes, I know it is "obvious" but it gets overlooked.


The point was that the file permissions generally didn't apply to the
metadata

If you mean you can run "ls" and see that a file is inaccessible then yes.
But then again there are situations where the 'ls' command displays a field of
question marks. perhaps the i-node is 'corrupt' or insensible. perhaps it is
inaccessible.


and there was (and still is) a *logical* separation.

Yes. But that shouldn't necessitate the 'hard' separation.

Where you physically put that isn't so relevant as the policies that mediate
access to them.

I take you point, but it is only relevant when there is 'no significant load'.
The fixed division models of inode separation all get into thrashing after
significant use does to searching over a fragments fixed array.

Now you may say that "performance isn't the issue here", and in an abstract that
may be so, but those same limits tend to bring other 'bugs' into the the light,
and while they may be true coding bugs, such as off-by-one errors they may also
be design concept errors; not necessarily errors in the data structures or data
content but in the coding of the algorithm (such as integer vs unsigned) or in
the design of the algorithm itself.

I've seen all of the above. I've seen all of the above in mature programs and
only emerge, as I say, when stressed in just the right way.
And I'm sure I'll see that again and again and again through the rest of my
life.



Please understand this wasn't about the physical location of
inode data, but the separation of meta-data and user-data. To emphasize the
point, xfs has a utility (I think ntfs used to have something similar but it
didn't dump everything), to just dump the meta-data for a partition (and
later allow restoring it) for various uses including backup-media that
doesn't store meta-data -- allowing meta-data to be stored as a separate
file.

It depends.
Perhaps you could detail that.
I can see that backing up a file can drop meta-data, or transform it (think:
running 'rsync' as root without ....

-p, --perms preserve permissions
-E, --executability preserve executability
-A, --acls preserve ACLs (implies -p)
-X, --xattrs preserve extended attributes
-o, --owner preserve owner (super-user only)
-g, --group preserve group
--devices preserve device files (super-user only)
--specials preserve special files
-D same as --devices --specials
-t, --times preserve modification times

And that skips over such information as links, symlinks and block sizes)


And, SORRY, but I DO think it has to do with "location".

The thing about the fixed allocation models of the UNIX V6/V7 (aka SCO or sysv)
and the BFFS is not mealy that they are in a specific (and therefore fixed)
location of the disk but that they are, therefore, fixed in size. They are not
extensible in the way that the B-tree systems are.

Sorry for any confusion. -linda

I think that I'm taking a broader view of this that you are.
I can see your point but I keep doing a "yes but..."

For example, on-disk data location, block pointers, is part of the data in an
i-node under the UNIX/Linux model, but there are file systems (e.g. from IBM)
where the i-node-equivalent holding the kind of meta-data about access is a
derivative of other 'pointers' ... and so is the storage. Then there are
non-file-system storage. The sort of databases where "you don't need to know
how they are physically constructed and it might not all be the same" and there
is record and field meta-data, access, locking and more. (IBM has a lot to
account for!)

There's a LOT of "yes, but..." out there.

--
"Nothing is more difficult to carry out, nor more doubtful of
success, nor more dangerous to handle, than to initiate a new
order of things." -- Machiavelli

--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups