EmbeddedRelated.com
Forums
The 2026 Embedded Online Conference

Verifying SD Cards

Started by rickman May 3, 2016
On 6.5.16 15:14, The Natural Philosopher wrote:
> On 06/05/16 11:39, Jasen Betts wrote: >> On 2016-05-06, rickman <gnuarm@gmail.com> wrote: >>> On 5/5/2016 1:00 PM, Rob wrote: >>>> >>>> Of course you use FAT32 only on cards/sticks/drives you want to use >>>> for quick worry-free interchange of files. The sneaker network. >>>> >>>> Any use of those devices for permanent storage in a system should of >>>> course use the native filesystem on that system or a filesystem >>>> optimized for flash storage. >>> >>> "Native" filesystem? What file system is native to Linux? >> >> EXT* >> >> > > Well its certainly mostly the default, but native?
The native filesystem on early Linuxes was the System III file system, also called Minix. Its capabilities are not enough for current versions. -- -TV
On Fri, 6 May 2016 13:14:56 +0100
The Natural Philosopher <tnp@invalid.invalid> wrote:

> On 06/05/16 11:39, Jasen Betts wrote: > > On 2016-05-06, rickman <gnuarm@gmail.com> wrote: > >> "Native" filesystem? What file system is native to Linux? > > > > EXT* > > Well its certainly mostly the default, but native?
Well extfs was the first filesystem written for Linux, followed rapidly by ext2fs, so I'd say it's the best contender there is for a native Linux filesystem. -- Steve O'Hara-Smith | Directable Mirror Arrays C:>WIN | A better way to focus the sun The computer obeys and wins. | licences available see You lose and Bill collects. | http://www.sohara.org/
In message <5q7libpnqqbd25sajfj73bp5e38gob63ug@4ax.com>
          Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:

> Try finding 1GB Compact Flash cards! (My BOSS BR-600 won't work with > 2GB CF cards -- though for real laughs, I have a 128MB [yes MB] TransFlash > sitting in arm's reach)
I have a 32MB (yes, MB) SD card I use in my Raspberry Pi! It runs RISC OS Pico, so is barely one quarter used :-) Bryan. -- RISC OS User Group Of London - http://www.rougol.jellybaby.net/ RISC OS London Show - http://www.riscoslondonshow.co.uk/
On 5/6/2016 9:30 PM, Bryan Hogan wrote:
> In message <5q7libpnqqbd25sajfj73bp5e38gob63ug@4ax.com> > Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote: > >> Try finding 1GB Compact Flash cards! (My BOSS BR-600 won't work with >> 2GB CF cards -- though for real laughs, I have a 128MB [yes MB] TransFlash >> sitting in arm's reach) > > I have a 32MB (yes, MB) SD card I use in my Raspberry Pi! > > It runs RISC OS Pico, so is barely one quarter used :-)
If card sellers fake the size by having the card report a number that is too large, is it possible to have the card report a smaller size and be compatible with older devices? I guess that would work as long as it is the same type of card speaking the same protocol. I believe the SDHC card is not really backward compatible with SD readers, etc. So even if an SDHC card reports its size as 1 GB, it still can't be used in older equipment. -- Rick C
Jasen Betts <jasen@xnet.co.nz> wrote:
> Kernel support exists for HPFS(IBM), NTFS(MS), HFS(Apple), XFS(SGI) > NFS(SUN), ZFS(SUN) etc. So by some measure these could also be > considered native.
It seems this word causes considerable confusion. As English is not my first language and I get vocabulary only by reading technical articles, it was my understanding that "native filesystem" means the filesystem the OS normally uses for full functionality. i.e. NTFS for Windows, Ext* or similar for Linux, etc. This as opposed to foreign filesystem support like NTFS for Linux, or legacy filesystem support like FAT for Windows. But apparently this is incorrect.
On Sat, 07 May 2016 07:20:02 +0000, Rob wrote:

> Jasen Betts <jasen@xnet.co.nz> wrote: >> Kernel support exists for HPFS(IBM), NTFS(MS), HFS(Apple), XFS(SGI) >> NFS(SUN), ZFS(SUN) etc. So by some measure these could also be >> considered native. > > It seems this word causes considerable confusion. > As English is not my first language and I get vocabulary only by reading > technical articles, it was my understanding that "native filesystem" > means the filesystem the OS normally uses for full functionality. > > i.e. NTFS for Windows, Ext* or similar for Linux, etc. > > This as opposed to foreign filesystem support like NTFS for Linux, or > legacy filesystem support like FAT for Windows. > > But apparently this is incorrect.
I use the term 'native filing system' pretty much the same way is you do, but, as often, the devil is in the details. For instance Linux also (used to) support reiserfs and (still supports) btrfs. As far as I can tell these have never been used with any other OS so should probably count as 'native fs' too. I suppose a good working definition of 'native' is "can a program or user tell the difference when accessing files in the fs?". By this measure FAT fails the test because its permission system won't map cleanly onto the UNIX/Linux rwxrwxrwx scheme. 'Read only' sort of works but the 'archive bit' has no equivalent and ends up being treated as something entirely different in some implementations, e.g SAMBA. I believe that ZFS maps directly onto POSIX permissions, etc. but I can't talk about HPFS, NTFS, XFS or NFS since I've never tried to mount them on a Linux box. 'Native fs' takes on rather a different meaning, though, when you're dealing with a software emulator running under Linux and emulating some other hardware and/or filing system. A decent example is os9exec, which emulates Microware's OS-9/68000 (aka OSK) which ran on Motorola 68000 hardware. Here 'native fs' means a collection of Linux files in a Linux directory hierarchy being made accessible to an OS-9 binary program running under os9exec, which lets programs running under it work equally well with a 'disk image', a large binary Linux file made by using dd to copy an OSK disk into a Linux file. IOW this contains OSK format files referenced by OSK directory structures sitting in 256 byte blocks that are binary images of OSK disk sectors. A lot of finangling is needed in the emulator when 'native' files and directories are being accessed because the emulator has to hide the different newlines (LF for Linux, CR for OSK) as well as doing on-the-fly directory entry remapping so that low-level OSK i/o functions in OSK programs can read and understand Linux directory entries. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
On Sat, 7 May 2016 08:18:17 -0000 (UTC), Martin Gregorie
<martin@address-in-sig.invalid> Gave us:

>On Sat, 07 May 2016 07:20:02 +0000, Rob wrote: > >> Jasen Betts <jasen@xnet.co.nz> wrote: >>> Kernel support exists for HPFS(IBM), NTFS(MS), HFS(Apple), XFS(SGI) >>> NFS(SUN), ZFS(SUN) etc. So by some measure these could also be >>> considered native. >> >> It seems this word causes considerable confusion. >> As English is not my first language and I get vocabulary only by reading >> technical articles, it was my understanding that "native filesystem" >> means the filesystem the OS normally uses for full functionality. >> >> i.e. NTFS for Windows, Ext* or similar for Linux, etc. >> >> This as opposed to foreign filesystem support like NTFS for Linux, or >> legacy filesystem support like FAT for Windows. >> >> But apparently this is incorrect. > >I use the term 'native filing system' pretty much the same way is you do, >but, as often, the devil is in the details. For instance Linux also (used >to) support reiserfs and (still supports) btrfs. As far as I can tell >these have never been used with any other OS so should probably count as >'native fs' too. I suppose a good working definition of 'native' is "can >a program or user tell the difference when accessing files in the fs?". > >By this measure FAT fails the test because its permission system won't >map cleanly onto the UNIX/Linux rwxrwxrwx scheme. 'Read only' sort of >works but the 'archive bit' has no equivalent and ends up being treated >as something entirely different in some implementations, e.g SAMBA. I >believe that ZFS maps directly onto POSIX permissions, etc. but I can't >talk about HPFS, NTFS, XFS or NFS since I've never tried to mount them on >a Linux box. > >'Native fs' takes on rather a different meaning, though, when you're >dealing with a software emulator running under Linux and emulating some >other hardware and/or filing system. A decent example is os9exec, which >emulates Microware's OS-9/68000 (aka OSK) which ran on Motorola 68000 >hardware. Here 'native fs' means a collection of Linux files in a Linux >directory hierarchy being made accessible to an OS-9 binary program >running under os9exec, which lets programs running under it work equally >well with a 'disk image', a large binary Linux file made by using dd to >copy an OSK disk into a Linux file. IOW this contains OSK format files >referenced by OSK directory structures sitting in 256 byte blocks that >are binary images of OSK disk sectors. A lot of finangling is needed in >the emulator when 'native' files and directories are being accessed >because the emulator has to hide the different newlines (LF for Linux, CR >for OSK) as well as doing on-the-fly directory entry remapping so that >low-level OSK i/o functions in OSK programs can read and understand Linux >directory entries.
I think it was an early version of Mandriva (Mandrake) which had a partition manager 'fdisk' application which allowed the operator to create a file system from a list of over 100 different ones. Why that went away, I do not know. https://en.wikipedia.org/wiki/List_of_file_systems What I do know is that ALL of them were of a nature that their very essence was shared with the world, and MicroSoft was the first to NOT release the particulars of a file system with their NTFS file system. So yet another departure from the standard paradigm the rest of the entire industry embraced. And AFAIK it is still not available and what Linux app developers have done is reverse engineer an app which allows them to be read, and subsequently figured out how to write to them. But the entire battery of particulars are still proprietary and unavailable. And their security is still nil, so it did not help them in that quest either. Pretty fuckin lame, IMO.
On 07/05/2016 08:20, Rob wrote:
> Jasen Betts <jasen@xnet.co.nz> wrote: >> Kernel support exists for HPFS(IBM), NTFS(MS), HFS(Apple), XFS(SGI) >> NFS(SUN), ZFS(SUN) etc. So by some measure these could also be >> considered native. > > It seems this word causes considerable confusion. > As English is not my first language and I get vocabulary only by reading > technical articles, it was my understanding that "native filesystem" > means the filesystem the OS normally uses for full functionality. > > i.e. NTFS for Windows, Ext* or similar for Linux, etc. > > This as opposed to foreign filesystem support like NTFS for Linux, or > legacy filesystem support like FAT for Windows. > > But apparently this is incorrect. >
Your understanding of native filing is more than acceptable Rob.
Am 07.05.2016 um 09:20 schrieb Rob:

> It seems this word causes considerable confusion. > As English is not my first language and I get vocabulary only by reading > technical articles, it was my understanding that "native filesystem" > means the filesystem the OS normally uses for full functionality.
Your understanding is fine, but there's an incorrect assumption buried underneath: the assumption that there is "the" native file system for a given OS, i.e. that there will be only _one_. Windows may leave casual observers under the impression that is has only one FS available, because it generally doesn't offer a choice of FS to the user. It just picks what Redmond decided was "best" for a given situation. And of course "WIndows" isn't actually one OS, it's a whole line of at least 3 distinct families: Windows 1 to 3, the Windows 9x family and the NT-based family. Each of those can be said to have a different native file system: FAT, FAT32 and NTFS, respectively. For Linux, OTOH, the concept of a single, clearly definable native FS breaks down almost completely. It has closer to a dozen.
On 2016-05-07, DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> wrote:
> On Sat, 7 May 2016 08:18:17 -0000 (UTC), Martin Gregorie ><martin@address-in-sig.invalid> Gave us: > >>On Sat, 07 May 2016 07:20:02 +0000, Rob wrote: >> >>> Jasen Betts <jasen@xnet.co.nz> wrote: >>>> Kernel support exists for HPFS(IBM), NTFS(MS), HFS(Apple), XFS(SGI) >>>> NFS(SUN), ZFS(SUN) etc. So by some measure these could also be >>>> considered native. >>> >>> It seems this word causes considerable confusion. >>> As English is not my first language and I get vocabulary only by reading >>> technical articles, it was my understanding that "native filesystem" >>> means the filesystem the OS normally uses for full functionality. >>> >>> i.e. NTFS for Windows, Ext* or similar for Linux, etc. >>> >>> This as opposed to foreign filesystem support like NTFS for Linux, or >>> legacy filesystem support like FAT for Windows. >>> >>> But apparently this is incorrect. >> >>I use the term 'native filing system' pretty much the same way is you do, >>but, as often, the devil is in the details. For instance Linux also (used >>to) support reiserfs and (still supports) btrfs. As far as I can tell >>these have never been used with any other OS so should probably count as >>'native fs' too. I suppose a good working definition of 'native' is "can >>a program or user tell the difference when accessing files in the fs?". >> >>By this measure FAT fails the test because its permission system won't >>map cleanly onto the UNIX/Linux rwxrwxrwx scheme. 'Read only' sort of >>works but the 'archive bit' has no equivalent and ends up being treated >>as something entirely different in some implementations, e.g SAMBA. I >>believe that ZFS maps directly onto POSIX permissions, etc. but I can't >>talk about HPFS, NTFS, XFS or NFS since I've never tried to mount them on >>a Linux box. >> >>'Native fs' takes on rather a different meaning, though, when you're >>dealing with a software emulator running under Linux and emulating some >>other hardware and/or filing system. A decent example is os9exec, which >>emulates Microware's OS-9/68000 (aka OSK) which ran on Motorola 68000 >>hardware. Here 'native fs' means a collection of Linux files in a Linux >>directory hierarchy being made accessible to an OS-9 binary program >>running under os9exec, which lets programs running under it work equally >>well with a 'disk image', a large binary Linux file made by using dd to >>copy an OSK disk into a Linux file. IOW this contains OSK format files >>referenced by OSK directory structures sitting in 256 byte blocks that >>are binary images of OSK disk sectors. A lot of finangling is needed in >>the emulator when 'native' files and directories are being accessed >>because the emulator has to hide the different newlines (LF for Linux, CR >>for OSK) as well as doing on-the-fly directory entry remapping so that >>low-level OSK i/o functions in OSK programs can read and understand Linux >>directory entries. > > I think it was an early version of Mandriva (Mandrake) which had a > partition manager 'fdisk' application which allowed the operator to > create a file system from a list of over 100 different ones. Why that > went away, I do not know.
0 still available for small disks Welcome to fdisk (util-linux 2.28). Changes will remain in memory only, until you decide to write them. Be careful before using the write command. Device does not contain a recognized partition table. Created a new DOS disklabel with disk identifier 0xe8caee2c. Command (m for help): n Partition type p primary (0 primary, 0 extended, 4 free) e extended (container for logical partitions) Select (default p): p Partition number (1-4, default 1): 1 First sector (2048-5530576, default 2048): Last sector, +sectors or +size{K,M,G,T,P} (2048-5530576, default 5530576): Created a new partition 1 of type 'Linux' and of size 2.7 GiB. Command (m for help): t Selected partition 1 Partition type (type L to list all types): l 0 Empty 24 NEC DOS 81 Minix / old Lin bf Solaris 1 FAT12 27 Hidden NTFS Win 82 Linux swap / So c1 DRDOS/sec (FAT- 2 XENIX root 39 Plan 9 83 Linux c4 DRDOS/sec (FAT- 3 XENIX usr 3c PartitionMagic 84 OS/2 hidden or c6 DRDOS/sec (FAT- 4 FAT16 <32M 40 Venix 80286 85 Linux extended c7 Syrinx 5 Extended 41 PPC PReP Boot 86 NTFS volume set da Non-FS data 6 FAT16 42 SFS 87 NTFS volume set db CP/M / CTOS / . 7 HPFS/NTFS/exFAT 4d QNX4.x 88 Linux plaintext de Dell Utility 8 AIX 4e QNX4.x 2nd part 8e Linux LVM df BootIt 9 AIX bootable 4f QNX4.x 3rd part 93 Amoeba e1 DOS access a OS/2 Boot Manag 50 OnTrack DM 94 Amoeba BBT e3 DOS R/O b W95 FAT32 51 OnTrack DM6 Aux 9f BSD/OS e4 SpeedStor c W95 FAT32 (LBA) 52 CP/M a0 IBM Thinkpad hi ea Rufus alignment e W95 FAT16 (LBA) 53 OnTrack DM6 Aux a5 FreeBSD eb BeOS fs f W95 Ext'd (LBA) 54 OnTrackDM6 a6 OpenBSD ee GPT 10 OPUS 55 EZ-Drive a7 NeXTSTEP ef EFI (FAT-12/16/ 11 Hidden FAT12 56 Golden Bow a8 Darwin UFS f0 Linux/PA-RISC b 12 Compaq diagnost 5c Priam Edisk a9 NetBSD f1 SpeedStor 14 Hidden FAT16 <3 61 SpeedStor ab Darwin boot f4 SpeedStor 16 Hidden FAT16 63 GNU HURD or Sys af HFS / HFS+ f2 DOS secondary 17 Hidden HPFS/NTF 64 Novell Netware b7 BSDI fs fb VMware VMFS 18 AST SmartSleep 65 Novell Netware b8 BSDI swap fc VMware VMKCORE 1b Hidden W95 FAT3 70 DiskSecure Mult bb Boot Wizard hid fd Linux raid auto 1c Hidden W95 FAT3 75 PC/IX bc Acronis FAT32 L fe LANstep 1e Hidden W95 FAT1 80 Old Minix be Solaris boot ff BBT Partition type (type L to list all types): gdisk (the GPT equivalent of fdisk) shows a shorter list as it onlt lists known GPT compatible operating systems. Hex code or GUID (L to show codes, Enter = 8300): 0700 Microsoft basic data 0c01 Microsoft reserved 2700 Windows RE 3000 ONIE boot 3001 ONIE config 3900 Plan 9 4100 PowerPC PReP boot 4200 Windows LDM data 4201 Windows LDM metadata 4202 Windows Storage Spac 7501 IBM GPFS 7f00 ChromeOS kernel 7f01 ChromeOS root 7f02 ChromeOS reserved 8200 Linux swap 8300 Linux filesystem 8301 Linux reserved 8302 Linux /home 8303 Linux x86 root (/) 8304 Linux x86-64 root (/ 8305 Linux ARM64 root (/) 8306 Linux /srv 8307 Linux ARM32 root (/) 8400 Intel Rapid Start 8e00 Linux LVM a500 FreeBSD disklabel a501 FreeBSD boot a502 FreeBSD swap a503 FreeBSD UFS a504 FreeBSD ZFS a505 FreeBSD Vinum/RAID a580 Midnight BSD data a581 Midnight BSD boot a582 Midnight BSD swap a583 Midnight BSD UFS a584 Midnight BSD ZFS a585 Midnight BSD Vinum a600 OpenBSD disklabel a800 Apple UFS a901 NetBSD swap a902 NetBSD FFS a903 NetBSD LFS a904 NetBSD concatenated a905 NetBSD encrypted a906 NetBSD RAID ab00 Recovery HD af00 Apple HFS/HFS+ af01 Apple RAID af02 Apple RAID offline af03 Apple label af04 AppleTV recovery af05 Apple Core Storage bc00 Acronis Secure Zone be00 Solaris boot bf00 Solaris root bf01 Solaris /usr & Mac Z bf02 Solaris swap bf03 Solaris backup bf04 Solaris /var bf05 Solaris /home bf06 Solaris alternate se bf07 Solaris Reserved 1 bf08 Solaris Reserved 2 Press the <Enter> key to see more codes: bf09 Solaris Reserved 3 bf0a Solaris Reserved 4 bf0b Solaris Reserved 5 c001 HP-UX data c002 HP-UX service ea00 Freedesktop $BOOT eb00 Haiku BFS ed00 Sony system partitio ed01 Lenovo system partit ef00 EFI System ef01 MBR partition scheme ef02 BIOS boot partition f800 Ceph OSD f801 Ceph dm-crypt OSD f802 Ceph journal f803 Ceph dm-crypt journa f804 Ceph disk in creatio f805 Ceph dm-crypt disk i fb00 VMWare VMFS fb01 VMWare reserved fc00 VMWare kcore crash p fd00 Linux RAID Hex code or GUID (L to show codes, Enter = 8300): but neither will actually create a filesystem, it only creates a partition tagged with that type, the partition will need to be formatted before it is usable. -- \_(&#12484;)_
The 2026 Embedded Online Conference