Committed as r320579, however I didn't add the CR link as there was no comment.

In D10315#236480, @kevans wrote:

Ping @emaste, anything else on this one?

Actually, on second thoughts, I see no advantage in using the enums so I will be committing the previous version.

I have to say it looks elegant. The big doubt is if it's worth it.
kevlo@ uses it more than I do ... any opinion?

Applying feedback from Fedor.

more bit mangling.

Update (again) the shifts: e2di_uid and e2di_gid are just uint16_t.

Fix the shifts.
Move the extended inode changes to one unique if block.
Support both RW on ext3.

For the record

In D11210#233240, @pfg wrote:

There is something wrong still, we cannot just bump i_nlink without considering how the information is stored on disk,

http://src.illumos.org/source/xref/freebsd-head/sys/fs/ext2fs/ext2_inode_cnv.c#89

In particular, e2di_nlink is still uint16_t (see ext2_dinode.h). The higher bits must be stored somewhere.

There is something wrong still, we cannot just bump i_nlink without considering how the information is stored on disk,

Approved with a sidenote:
The helpers to increment and decrement i_nlink involve a deviation to how it's done in UFS.
I don't see any way around it, it's just the way ext4 works.

LGTM

OK, I'll bite this .. besides, it just can't hurt,

Note to self: I think this feature may work on ext3 so it can be tested with tune2fs.

In D11209#232927, @thisisadrgreenthumb_gmail.com wrote:

In D11209#232380, @pfg wrote:

I think the flag is unnecessary in this case due to the way the feature flags work:

• ROCOMPAT means that even if not supported we can mount the file system (which we do).
• defining the feature would mean we support it fully, which would imply write support.

Unfortunately, we can mount it only in READ ONLY mode, but we need RW, because, this feature is usefull on relatively old linux distros.

For the case where EXT2F_ROCOMPAT_DIR_NLINK is defined, should be able to handle more that 65000 links.
This code doesn't support that case so we are not really supporting the feature.

Looks good to me.

I don't see EXT4_LINK_MAX (?):

I think the flag is unnecessary in this case due to the way the feature flags work:

In D11209#232007, @thisisadrgreenthumb_gmail.com wrote:

The code from ext2_inode_cnv.c could be removed until bigalloc will not be added. But in all cases EXT2F_ROCOMPAT_HUGE_FILE should be placed in correct place, because it is useful feature and we can not mount drives to RW mode.

In D11211#232008, @thisisadrgreenthumb_gmail.com wrote:

Ok, you are right, I will try to add file like ext2_csum.c

In D11210#231998, @thisisadrgreenthumb_gmail.com wrote:

But we able to set 65000. I tested it on x86_64, but I can see the same for 32 bit platforms _types.h:
typedef uint64_t nlink_t; /* link count */

Actually: va_nlink is now nlink_t, this was a change for INO64, but the illumos' opengrok hasn't caught up.
The change is fine, but only on -current.

In D11208#231970, @thisisadrgreenthumb_gmail.com wrote:

Sorry, but I did not get your idea, what use instead of struct in this case?

I don't know much about this feature but it is probably interesting enough to put all the new functionality in a different file.
ext2_alloc is already crowded.

This is probably fine but I suspect this code has never been tested: a HUGE_FILE doesn't fit in a ext2 partition so the feature implies ext4. It also will take quite long to read/write so I would assume the filesystem will require some special implementation magic.

This patch doesn't implement dir_nlink: by enabling dir_nlink you should be able to set up more than 65000 links. (linux extends the number of links somewhere, don't remember).

This makes sense, but I am not sure we want to use a struct for that.
Not an objection, just a comment.

BTW.. don't waste time updating this.. the changes are trivial so I will just do them locally.

Haven't compile-tested yet ...
/* !UFS_ACL */ is wrong in these cases.

oops ..yes.

LGTM, Thanks!

Most of the packages that use this involve MPI: I need the MPICH build for another port I am working in (sundials), however we could also use OpenMPI.

I like bools too :).

In D10945#228108, @araujo wrote:

...

I know you have abandoned this patch already, but I'd like to share my point of view.
Replace inline by macros has some benefits that is not only related with performance, of course each case need to be analysed, but one big benefit for me is 'code consistency' and also sometimes it makes easier to read the code as well.

So, performance is not the only and main point for these changes.

Yes.. thanks to pluknet for finding the bug.

Looks good to me.

It is not incorrect but it looks somewhat weird: Perhaps it's just an off-by-one and changing k >=0 to k > 0 in line 620 solves it more cleanly.

After reading a bunch of pros and cons between inline vs. macros, I got to the conclusion that it doesn't really matter. at least not for this case, and not something I want to spend time benchmarking.

In D10945#226592, @delphij wrote:

In D10945#226591, @pfg wrote:

In D10945#226586, @delphij wrote:

What do we gain from the change?

Performance.. if we do them a lot it may be noticeable.

Do you have data to support this claim? (e.g. I don't see why inline expansion is different from macro expansion in the resulting code).

In D10945#226586, @delphij wrote:

What do we gain from the change?

Performance.. if we do them a lot it may be noticeable.

exp-run issues (from PR 218495) have been resolved now.

In D10807#224273, @thisisadrgreenthumb_gmail.com wrote:

:) May be I said about copy-paste too roughly, but I will lie if I say that I do not use the linux source code.

In D10807#224256, @thisisadrgreenthumb_gmail.com wrote:

The reason, why I prefer to leave these functions as is, because it is mostly copy-paste from ext4 linux sources, and if somebody will try to compare it with original, it will be simpler.

Minor issues.. would like to see some feedback from others.

This has basically all the changes I have tried to avoid.

LGTM