for the same file, the file size obtained using ll and eza -l is inconsistent.

[usernameisnull]

root in 󱃾 a223(default) /tmp took 2s
❯ eza -l /tmp/output.csv
.rw-r--r-- 99M root 25 Dec 18:02 /tmp/output.csv

root in 󱃾 a223(default) /tmp
➜ ll /tmp/output.csv
-rw-r--r-- 1 root root 95M Dec 25 18:02 /tmp/output.csv

[ngtv2409]

I tested a few cases and it seems like it is due to the unit mismatch, where ls is using MiB, that is, MB in base 2 — 1024B, while eza using MB in base 10 = 1000B.

I am at least 70% confident because of this test case:

truncate -s 36500000 test.bin # POSIX

This reserves a file of size 36500000 bytes, which is around 34.8 MiB and 36.5 MB

The ls -l outputs 35M while eza -l outputs 37M. Which matches the expectation above after rounding to nearest integer.

[usernameisnull]

Is there any option that can be set to make this unit consistent with the one used by ls on Linux?

[ngtv2409]

Is there any option that can be set to make this unit consistent with the one used by ls on Linux?

Try using

-b, --binary: list file sizes with binary prefixes

It will show the same way, though it will display Mi rather than M. So 35Mi

Why would you want that though?

[usernameisnull]

yes, that is great, thank you
root in 󱃾 a223(default) /tmp
➜ ll 95M_file
-rw-r--r-- 1 root root 95M Jan 9 11:31 95M_file

root in 󱃾 a223(default) /tmp
➜ eza -l 95M_file
.rw-r--r-- 100M root 9 Jan 11:31 95M_file

root in 󱃾 a223(default) /tmp
➜ eza -lb 95M_file
.rw-r--r-- 95Mi root 9 Jan 11:31 95M_file

[usernameisnull]

thank you @ngtv2409