Re: VFAT vs. umask.
On Wed 03 Aug 2022 at 08:37:24 (-0700), peter@easthope.ca wrote:
> From: David Wright <deblis@lionunicorn.co.uk>
> Date: Sun, 31 Jul 2022 14:15:26 -0500
> > So "primary store" probably means Master Copy of Your Data.
>
> https://en.wiktionary.org/wiki/primary#Adjective sense 2.
> https://en.wiktionary.org/wiki/master#Adjective sense 2.
> https://en.wiktionary.org/wiki/store#Noun sense 4.
Yes, that last one is no help, usually triggering a HelpDesk-type
explanation of the difference between memory and storage.
As for primary store, the primary location for my photographs is
an SD card, but the first thing I do is transfer it to the master
location on spinning rust, check it, and back it up, before deleting
the primary store to avoid a "Memory Full" (sic) incident occurring
later, in the field.
So rather than a back and forth at cross-purposes (like that with
NAT and IPv6), I stated what /I/ thought your description meant.
> > ... copy it off the SD onto a hard drive to work on it, then put it
> > back (hopefully with care, not overwriting, and thorough flushing¹).
>
> I never do that. I use a file on the SD just as if it's on a spinning
> hdd.
OK, now we know where we stand. Your working methods and priorities
are so different from mine that it's easy to end up with crossed lines.
I run one system where the main drive is an SSD, but I've only run a
system on a flash drive (it was a USB rather than an SD) once, and
just as an experiment, for the challenge of installing an EFI bootable
system. That's a far worse case, of course, because it puts / onto the
flash drive, whereas presumably yours only involves a subdirectory.
> > ... reformat the card to an ext format and you can forget about that.
>
> According to several other messages alignment and block size are
> concerns in reformatting.
I'm using format in the sense used by the rest of the world, which you
and Charles would call a "high-level format" judging from posts like:
https://lists.debian.org/debian-user/2022/07/msg00768.html
https://lists.debian.org/debian-user/2022/07/msg00743.html
IOW, I meant what's done by mkfs.foo, except I was assuming that
you'd make an adjustment to the Partition Type first.
So I hadn't envisaged your considering a change in the partition's
/alignment/, which appears to be perfect, both at the beginning and,
more unusually, the end.
As for block size, yes, there are advantages to matching the
filesystem parameters with the underlying firmware's allocation
and erase units, but AFAICT the only way to reliably determine
the latter is by running timing experiments on the specific type
of device.
Much of this might be moot: allegedly there are design decisions
in how the cards operate that may be more important in determining
how fast the card is in use, particularly with different
filesystems, like FAT and ext, eg using a different strategy for
handling the start of the card, assumed to be the location of the
FAT's file allocation table itself.
As I pointed out, this might not make such a huge difference for the
use I thought you were making of the card, but I haven't a clue what
the effect might be when it's the file storage being used by your
programs while they're executing. That would require knowing how
the programs used it.
So it's quite possible that sticking with FAT is a better bet.
It was never clear to me what your permission problem with using
FAT actually was in the first place. Your OP read like some sort
of riddle or paradox that we were meant to solve, which we did.
(It's the driver wotduzit.)
Cheers,
David.
Reply to: