Activity for Phillip Lougher
-
Phillip Lougher posted a comment on ticket #2302
Just forget about those 3 bytes OK. They're completely unimportant for you. Clear enough?
-
The + 3 is 1 byte for ".", and 2 bytes for "..". These 3 bytes are not present in the on-disk >file, but are part of the "logical size" of the directory. Arguably, since that data isn't >actually in the file itself, the kernel code could have just added 3 to the size of the inode >it uses for directory inode types, but that is what the format is, and I don't think it's >changeable at this point. Think about those 3 bytes as part of the compression, or removal of unnecessary data. Just because they're...
-
. is one character .. is two characters. 1 + 2 == 3. It is the length of "." plus the length of "..". Surely, that is easy to understand. I didn't write your code, if you find it illogical that's not my problem. But, think of it this way. V3 directories are always 3 byes or larger in size. That's because they have "." and ".." entries. An empty directory will always have "." and "..". V2 and before did not have "." or "..". So an empty directory is ZERO bytes in size. There is no inconsistency here....
-
Actually I don't understand my code: if (_h.Major >= 3) { if (fileSize < 3) return S_FALSE; fileSize -= 3; } It looks illogical, when we reduce fileSize for 3 bytes here. Why we do it only for MajorVersion >= 3? It looks like workaround for some bug of encoder squashfs code. No. Squashfs in versions 1 & 2 did not store ".", or ".." entries in directories. More importantly, when returning the list of files (directory contents) to the kernel it didn't return "." or ".." entries. That was OK. The Linux...
-
Also https://github.com/torvalds/linux/blob/master/fs/squashfs/dir.c#L116
-
What are "old squashfs" and "new squashfs"? There is no "new" Squashfs. Squashfs-tools-ng is just a third-party implementation, like there are implementations for Python, Squashfs FUSE etc. Do not mistake it for some new tooling that replaces my Squashfs-tools, because it isn't. I still don't understand about 3 bytes. Why old squashfs has that 3 bytes difference in most squashfs files? why it's 3 bytes, but not 1,2,3,4 bytes? Is it some bug of original (old) code squashfs? No. the extra three bytes...
-
I've typically been running mksquashfs on nodes with 12 cores and 24 GB RAM, probably...
-
as it's a fairly unique one (Pleiades at NASA Ames). Do you mean this? Pleiades Supercomputer...
-
A couple of initial thoughts You state you upgraded to 4.3, but, the problem still...
-
squash lock the kernel
-
Fixed in kernel 3.3, upstream commit hash e552a596687bf0e1802c744a7bb113afbd2bf4...
-
This is a Squashfs filesystem generated by squashfs-tools modified by a third party....
-
unsquashfs 4.2 fail to unpack ROM img of different endiannes
-
Bug in Mksquashfs fixed in Squashfs tools 4.3 release
-
mksquahsfs segfaulted at the end of the process
-
Fixed in Squashfs tools 4.3
-
unused dump_pseudo
-
Fixed in Squashfs tools 4.3
-
mksquashfs exhaust all file descriptors in system on more pseudo files
-
Fix test for i386
1