Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Block-size needs to be specified even for --stat #70

Open
tabarnakos opened this issue Jul 10, 2024 · 3 comments
Open

Block-size needs to be specified even for --stat #70

tabarnakos opened this issue Jul 10, 2024 · 3 comments

Comments

@tabarnakos
Copy link

tabarnakos commented Jul 10, 2024

After compiling littlefs-fuse, I create a disk for the PIC32MZEF2048EFG, which has 16kB flash blocks. After many unsuccessful attempts, I finally made it work. The --stat command requires the block_size parameter to work, otherwise it seems to assume 512 bytes. This kind of defeats the purpose of the stat command.

WORKING INSTRUCTIONS:

create a 1MiB file system with all 0xFF

dd if=/dev/zero bs=1M count=1 | tr "\000" "\377" > image.lfs

finds a free loop device

sudo losetup -f
/dev/loop46

attach the loop device to the image create above

sudo losetup /dev/loop46 image.lfs

formats the lfs file system (successful)

./lfs --block_size=16384 --format /dev/loop46

mount the device (successful)

./lfs --block_size=16384 /dev/loop46 mnt

NON-WORKING INSTRUCTIONS:
./lfs --stat /dev/loop46
littlefs/lfs.c:1369:error: Corrupted dir pair at {0x0, 0x1}
lfs_fuse.c:644:error: Invalid or incomplete multibyte or wide character

./lfs /dev/loop46 mnt
littlefs/lfs.c:1369:error: Corrupted dir pair at {0x0, 0x1}
lfs_fuse.c:673:error: Invalid or incomplete multibyte or wide character

@rcmcdonald91
Copy link

I've actually got a patch in progress that addresses this. Here is the general idea:

  • When we --format without specifying --block_size, we honor the sector size reported by the OS for the underlying block device. When we do specify --block_size, we use that instead.
  • When we mount or --stat without specifying --block_size we scan the superblock for the block size and use that. --block_size should also be validated based on the minimum possible size, which I believe is a function of the sizeof superblock. Someone correct me, if that is incorrect.
  • --block_size=auto would become the new default and enforce the above rules.

Thoughts?

@tabarnakos
Copy link
Author

When we --format without specifying --block_size, we honor the sector size reported by the OS for the underlying block device. When we do specify --block_size, we use that instead.

Since the main purpose of lfs-fuse ( for me at least ) is not to use it as a file system on the PC, but rather to create images that I can natively flash onto my embedded system, there is no real correlation between littlefs-fuse block size and littlefs block size. Having a default behavior is nevertheless desirable.

When we mount or --stat without specifying --block_size we scan the superblock for the block size and use that. --block_size should also be validated based on the minimum possible size, which I believe is a function of the sizeof superblock. Someone correct me, if that is incorrect.

That was my understanding of the --stat argument in the beginning: to get information about the filesystem. Regarding block size, from the documentation

Note that the maximum number of pointers in a block is bounded by the maximum file size divided by the block size. With 32 bits for file size, this results in a minimum block size of 104 bytes.

--block_size=auto would become the new default and enforce the above rules.

Agreed.

@geky
Copy link
Member

geky commented Feb 6, 2025

Hi @tabarnakos, @rcmcdonald91.

This is a fundamental. littlefs cannot mount the filesystem without knowing the block size. See littlefs-project/littlefs#349 for more info.

When we mount or --stat without specifying --block_size we scan the superblock for the block size and use that.

This is enticing, but does not work if the first superblock is erased/mid-compaction. You can still mount with the second superblock in this case, but only if you know the block size.

You could try to also scan for the second superblock, but this will end up needing to read 1/2 of the entire block device to rule out extremely large block sizes.

Keep in mind 2-block-mode (block_size = disk_size/2) is common in very small filesystem images.

This is not a problem for other filesystems because they mostly rely on a small set of known block sizes.

Since the main purpose of lfs-fuse ( for me at least ) is not to use it as a file system on the PC, but rather to create images that I can natively flash onto my embedded system, there is no real correlation between littlefs-fuse block size and littlefs block size. Having a default behavior is nevertheless desirable.

This is a good perspective. I can see how the current behavior can end up really confusing.

To be honest, I'm sort of on the opinion of deprecating the automatic block_size detection entirely, and making -b/--block_size a required argument.

Adding -bauto/--block_size=auto is also a nice idea. We could add that for convenience, but make it opt-in to avoid confusion.

Another idea is we could limit the automatic behavior to files where fstat reports the type as S_IFBLK. Sorry scratch that. This wouldn't work with loop devices.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants