ultimate storage hack
-
Good luck with your 256 characters.
255, generally, because null termination. ZFS does 1023, the argument not being "people should have long filenames" but "unicode exists", ReiserFS 4032, Reiser4 3976. Not that anyone uses Reiser, any more. Also Linux' PATH_MAX of 4096 still applies. Though that's in the end just a POSIX define, I'm not sure whether that limit is actually enforced by open(2)... man page speaks of ENAMETOOLONG but doesn't give a maximum.
It's not like filesystems couldn't support it it's that FS people consider it pointless. ZFS does, in principle, support gigantic file metadata but using it would break use cases like having a separate vdev for your volume's metadata. What's the point of having (effectively) separate index drives when your data drives are empty.
-
I had a manager once tell me during a casual conversation with complete sincerity that one day with advancements in compression algorithms we could get any file down to a single bit. I really didn't know what to say to that level of absurdity. I just nodded.
You can give me any file, and I can create a compression algorithm that reduces it to 1 bit. (*)
::: spoiler spoiler
(*) No guarantees about the size of the decompression algorithm or its efficacy on other files
::: -
255, generally, because null termination. ZFS does 1023, the argument not being "people should have long filenames" but "unicode exists", ReiserFS 4032, Reiser4 3976. Not that anyone uses Reiser, any more. Also Linux' PATH_MAX of 4096 still applies. Though that's in the end just a POSIX define, I'm not sure whether that limit is actually enforced by open(2)... man page speaks of ENAMETOOLONG but doesn't give a maximum.
It's not like filesystems couldn't support it it's that FS people consider it pointless. ZFS does, in principle, support gigantic file metadata but using it would break use cases like having a separate vdev for your volume's metadata. What's the point of having (effectively) separate index drives when your data drives are empty.
...Just asking, just asking: Why is the default
FILENAME_MAXon Linux/glibc4096? -
System shared this topic on
-
...Just asking, just asking: Why is the default
FILENAME_MAXon Linux/glibc4096?Because PATH_MAX is? Also because it's a 4k page.
FILENAME_MAX is not safe to use for buffer allocations btw it could be INT_MAX.
-
Because PATH_MAX is? Also because it's a 4k page.
FILENAME_MAX is not safe to use for buffer allocations btw it could be INT_MAX.
Thanks! Got an answer and not 200 downvotes. This is why I love Lemm-Lemm.
-
each file is minimum 4kb
(base64.length/max_character) * min_filesize < actual_file_size
For this to pay off
Just use folders instead
-
each file is minimum 4kb
(base64.length/max_character) * min_filesize < actual_file_size
For this to pay off
each file is minimum 4kb
$ touch empty_file $ ls -l total 8 -rw-rw-r-- 1 user group 0 may 14 20:13 empty_file $ wc -c empty_file 0 empty_fileHuh?
-
You can give me any file, and I can create a compression algorithm that reduces it to 1 bit. (*)
::: spoiler spoiler
(*) No guarantees about the size of the decompression algorithm or its efficacy on other files
:::Here's a simple command to turn any file into a single b!
echo a > $file_name -
each file is minimum 4kb
$ touch empty_file $ ls -l total 8 -rw-rw-r-- 1 user group 0 may 14 20:13 empty_file $ wc -c empty_file 0 empty_fileHuh?
Oh, I'm thinking folders aren't I. Doy....
-
Oh, I'm thinking folders aren't I. Doy....
It seems those are 4 KiB on Linux, interesting to know.
