FAT32 vs EXT4 for Sentry Mode?

[GPinzone]

I don't have any issues with FAT32 for Sentry Mode. (Yes, there are some cameras that have partially corrupted video, but I believe that's not unique to me.) Is there any advantage to using EXT4? The partition for Sentry Mode is always corrupted when I remove the thumb drive even if I stop recording first. Since EXT4 is a journaling file system, would that be better?

 

[Tomed]

I don't have any issues with FAT32 for Sentry Mode. (Yes, there are some cameras that have partially corrupted video, but I believe that's not unique to me.) Is there any advantage to using EXT4? The partition for Sentry Mode is always corrupted when I remove the thumb drive even if I stop recording first. Since EXT4 is a journaling file system, would that be better?

Sentry mode does not support anything other than FAT32 for the moment. I do get partially corrupted video from time to time, but the is not corrupted. At least Disc doctor on MacOS says it's ok. Could it be that your computer corrupts the drive?

 

[KerryOH]

Could it be that your computer corrupts the drive?

I doubt it is Mac, I have a Win10 PC get the same issues with FAT32 and at last count 5 different flash drives from different manufacturers. I am currently testing a Transcend heavy duty micro SD with a USB adapter that was recommended on the forum. It wouldn't be a big problem except that last month my touchscreen locked up (see attachment) multiple times and eventually reboots did not resolve it. I scheduled service call but before the date virtual service checked the car and found that there was no room in memory due to flash drive errors. They created space in memory and I have not used the dash cam other than some tests with new drives. OP if you see the message below it is related to your issue.

 

[solodogg]

I don't have any issues with FAT32 for Sentry Mode. (Yes, there are some cameras that have partially corrupted video, but I believe that's not unique to me.) Is there any advantage to using EXT4? The partition for Sentry Mode is always corrupted when I remove the thumb drive even if I stop recording first. Since EXT4 is a journaling file system, would that be better?

Change your partition table style to GUID/GPT instead of MBR. No issues with corruption at all after doing this.

 

[srs5694]

Is there any advantage to using EXT4? The partition for Sentry Mode is always corrupted when I remove the thumb drive even if I stop recording first. Since EXT4 is a journaling file system, would that be better?

The one time I tried ext4fs for the TeslaCam partition, it did not work for me. I've heard that ext4fs works for music, but not for TeslaCam/Sentry Mode, but I've not tried ext4fs for music.

Also and FWIW, a journal doesn't really prevent filesystem damage. Its benefit is that it can speed recovery when a filesystem is improperly unmounted and then repaired. This can be a big deal on a big filesystem will lots of files, but the number of files on a TeslaCam disk is likely to be quite small, so I wouldn't expect this to be a big deal. That said, FAT is an ancient filesystem with a lot of drawbacks. I don't know if it's really any worse for TeslaCam use than ext4fs would be if ext4fs worked, though.

Change your partition table style to GUID/GPT instead of MBR. No issues with corruption at all after doing this.

I'm skeptical that this would make a difference. The partition table type is entirely independent of the filesystem used on the partition(s), and the corruption people have reported is entirely a filesystem issue, AFAIK. In the case of TeslaCam, it appears that the Tesla does not unmount the filesystem when you stop recording, which means that operations are likely to be cached, and not written to disk, when you pull the drive out. This will result in filesystem damage whether you use MBR or GPT. If you're lucky, that damage will be minor and, perhaps, corrected automatically in one way or another. I've seen claims that Tesla has begun running filesystem checks on its TeslaCam partition from time to time, but I can't confirm this myself. If true, it could be that the addition of these filesystem checks corresponded to when you changed from MBR to GPT, which may be why you saw a drop in filesystem damage.

FWIW, I use GPT on my TeslaCam/music drive, and I can tell when I examine it on my PC that the filesystem was not properly unmounted, even when I touch the icon to have the Tesla stop recording. That would result in no more or less damage if the disk used MBR rather than GPT.

 

[solodogg]

I'm skeptical that this would make a difference. The partition table type is entirely independent of the filesystem used on the partition(s), and the corruption people have reported is entirely a filesystem issue, AFAIK. In the case of TeslaCam, it appears that the Tesla does not unmount the filesystem when you stop recording, which means that operations are likely to be cached, and not written to disk, when you pull the drive out. This will result in filesystem damage whether you use MBR or GPT. If you're lucky, that damage will be minor and, perhaps, corrected automatically in one way or another. I've seen claims that Tesla has begun running filesystem checks on its TeslaCam partition from time to time, but I can't confirm this myself. If true, it could be that the addition of these filesystem checks corresponded to when you changed from MBR to GPT, which may be why you saw a drop in filesystem damage.

FWIW, I use GPT on my TeslaCam/music drive, and I can tell when I examine it on my PC that the filesystem was not properly unmounted, even when I touch the icon to have the Tesla stop recording. That would result in no more or less damage if the disk used MBR rather than GPT.

“GPT also stores cyclic redundancy check (CRC) values to check that its data is intact. If the data is corrupted, GPT can notice the problem and attempt to recover the damaged data from another location on the disk. MBR had no way of knowing if its data was corrupted—you’d only see there was a problem when the boot process failed or your drive’s partitions vanished.”

Source: https://www.howtogeek.com/193669/whats-the-difference-between-gpt-and-mbr-when-partitioning-a-drive/

 

[srs5694]

“GPT also stores cyclic redundancy check (CRC) values to check that its data is intact. If the data is corrupted, GPT can notice the problem and attempt to recover the damaged data from another location on the disk. MBR had no way of knowing if its data was corrupted—you’d only see there was a problem when the boot process failed or your drive’s partitions vanished.”

Source: What’s the Difference Between GPT and MBR When Partitioning a Drive?

Yes, but that applies to the partition table data, not to the filesystem data. In MBR, the partition table consumes precisely one sector (unless you use extended/logical partitions, in which case each logical partition consumes one more sector for partition table data). GPT consumes 67 sectors, assuming the default sizes. A 32GiB device has something on the order of 67 million sectors, by contrast, so something like one in a million sectors on the disk is used by partition table data on a disk of that size. In the case of both MBR and GPT, the partition table sectors are written once and then left alone; they aren't (or shouldn't be) re-written on a regular basis, unlike filesystem data, which in a read/write application like TeslaCam, will be written frequently. In other words, the odds of problems developing in the partition table data are exceedingly slim, so switching from MBR to GPT is unlikely to have had a noticeable effect on something like data corruption in a TeslaCam drive. Also, because GPT uses 67 times as many sectors as MBR, the odds of a random problem affecting GPT are actually greater than the odds of such a problem affecting MBR. GPT's CRCs simply make it easier to detect such a problem, and the redundant coding makes it easier to recover from such a problem.

Furthermore, corruption of the partition table data would result in very different symptoms from corruption of filesystem data. The former is likely to result in a completely inaccessible filesystem, whereas the latter will be more likely to result in damaged files. I get the impression that most people who've had problems see damaged files; they can still access the filesystem. That said, some types of filesystem damage might make it impossible to mount the filesystem, which would be similar in appearance to some types of partition table damage; you'd need a fairly deep dive into the partition table and/or filesystem data structures to figure out which type of damage caused the symptom.

 

[lenb3]

I'm using a single USB drive for music and TeslaCam/sentry mode,
to keep the 2nd USB port on my model X available for phone charging.

My drive is a SanDisk SSD: https://www.amazon.com/gp/product/B07S1PCSV5
I use a right angle USB cable and route the cable to the drive under the tray on my model X, where the drive is out of the way.

Using the Ubuntu disk utility, I created two partitions on the drive (Yes, GPT style partition table) and formatted each partition with FAT32.

For the camera file system, I simply created the TeslaCam directory.
For the music file system, I copied a collection of CDs, which I ripped on my Mac into ALAC, and converted into FLAC with TeslaTunes.

This all works very well, except when it doesn't...

First, I too get some empty and corrupted video files when I pull the drive out and examine it with my computer.
If there is a way to tell the car that it is time to eject (flush & unmount) the file system before I physically extract it, that would be the first thing to try to address this problem.

More interesting, perhaps, would be the ability to view and manage the USB drive's contents on the 17" Tesla screen, and with the Tesla app on my phone.

Second, An EXT4 file system worked for the camera partition. "chmod 777 TeslaTunes", was sufficient to open up security to Tesla. The camera service in the car writes files with uid 1984 (heh). But the experience wasn't any better with EXT4. Although fsck can repair the file system, it can't invent data blocks that the car never flushed to the drive before the drive was pulled out of the car.

Third, I was not able to get the USB music app on the Tesla to see the music on EXT4. So I went back to FAT32. FAT32 more convenient anyway, since I usually generate the music files on my Mac, which can handle FAT32, but not EXT4. Speaking of my mac, TeslaTunes crashed it three times in the process of converting 6,000 FLAC files. Never seen that before... Happily, that app can pick up where it left off.

Finally, I have experienced the Tesla audio app failing to read a song part way through, and stopping. But every time this has happened, it works fine if I re-start the song. No idea where the actual error lies, but it would be nice if app were a little more robust in the face of intermittent errors.

Model X, September 2019
Firmware Version 2019.32.12.2

 

[sduck]

First, I too get some empty and corrupted video files when I pull the drive out and examine it with my computer.
If there is a way to tell the car that it is time to eject (flush & unmount) the file system before I physically extract it, that would be the first thing to try to address this problem.

My experience is with the model 3, but i suspect it's the same with the X - press and hold the dashcam icon at the top of the screen until it "flashes", then you can safely pull the drive.

More interesting, perhaps, would be the ability to view and manage the USB drive's contents on the 17" Tesla screen, and with the Tesla app on my phone.

Yes, we're all right there with you on this wish. Maybe it'll happen. It certainly could happen.

Second, An EXT4 file system worked for the camera partition. "chmod 777 TeslaTunes", was sufficient to open up security to Tesla. The camera service in the car writes files with uid 1984 (heh). But the experience wasn't any better with EXT4. Although fsck can repair the file system, it can't invent data blocks that the car never flushed to the drive before the drive was pulled out of the car.

Yes, they added this ability fairly recently.

Third, I was not able to get the USB music app on the Tesla to see the music on EXT4. So I went back to FAT32. FAT32 more convenient anyway, since I usually generate the music files on my Mac, which can handle FAT32, but not EXT4.

EXT4 definitely works for the music partition on the model 3 - I've been using it since march maybe, maybe earlier. I use an extension from Paragon Software that enables ext4fs on macs, it makes it transparent, works perfectly on my mac. The car seems to prefer ext4 - it catalogs the files really quickly, almost instantaneously.

Finally, I have experienced the Tesla audio app failing to read a song part way through, and stopping. But every time this has happened, it works fine if I re-start the song. No idea where the actual error lies, but it would be nice if app were a little more robust in the face of intermittent errors.

Yes, I've had that happen quite a bit - but i think it's something they've been working on. Some recent software versions it got really bad, but the newest one, it doesn't seem to be doing it anymore, although now the problem is the car doesn't remember where you are over power cycles reliably. Another issue that I've had is the ends of songs getting cut off - maybe just the last 2 or 3 seconds, but that can be really annoying sometimes. I bug support relentlessly on this - I'm too much of a music head, and they didn't give us an aux jack to plug something reliable into. I think a big part of the problem is that they don't buffer the digital audio stream, or they don't buffer it enough.

 

[superblast]

Another issue that I've had is the ends of songs getting cut off - maybe just the last 2 or 3 seconds, but that can be really annoying sometimes. I bug support relentlessly on this - I'm too much of a music head, and they didn't give us an aux jack to plug something reliable into. I think a big part of the problem is that they don't buffer the digital audio stream, or they don't buffer it enough.

I haven't seen that issue of music being cut off in my Model 3. I pretty much always have USB music playing while I'm in the car and it would bug the crap out of me if songs were being cut off. Are you playing FLACs or MP3s or both? My USB has only 320k MP3s on it. Most were converted from FLACs using dbpoweramp but there's a few paid downloads mixed in.

 

[sduck]

It doesn't happen that often, but I first noticed it with an album by Weezer from Itunes, that was m4a's. The worst offenders seem to be flac files. MP3 files - never have this problem.

 

[superblast]

It doesn't happen that often, but I first noticed it with an album by Weezer from Itunes, that was m4a's. The worst offenders seem to be flac files. MP3 files - never have this problem.

Good to know.

 

[srs5694]

My experience is with the model 3, but i suspect it's the same with the X - press and hold the dashcam icon at the top of the screen until it "flashes", then you can safely pull the drive.

That doesn't actually unmount the filesystem; it simply stops recording. If you wait a few seconds, the Tesla's computer is likely to flush the filesystem (I suppose it's possible that Tesla does this when recording stops, but I haven't seen that documented anywhere); but stopping recording will not unmount the filesystem -- at least, not in my experience. Every time I've pulled the USB drive from my Tesla and checked it on a regular computer, it's shown up with its "dirty bit" set, meaning that it has not been fully unmounted, even when I explicitly tell the car to stop recording first. Even the flushing of the filesystem is uncertain; that's entirely up to the OS for when this will happen. As I said, it's conceivable that Tesla does this as part of the "stop recording" action, but I don't know of a reliable way to check that, offhand.

There have been numerous reports of filesystem damage on TeslaCam devices (mostly using FAT32), but some of those may have been caused by people pulling drives before stopping recording. I seem to recall seeing some discussion a few months ago about how such problems had been coming down in frequency. Maybe that's been a matter of better user practices; or maybe Tesla implemented something like the above-speculated flush-after-stopping-recording activity, or tweaked mount options to minimize options.

In any event, I agree with @lenb3 that a better means for forcing a proper filesystem unmount operation is in order. OTOH, most people haven't a clue about what that means, and it would complicate the UI design, so maybe it's OK the way it is, especially if Tesla flushes the filesystem when you tell it to stop recording. In the meantime, stopping recording before pulling the drive, as you suggest, is certainly likely to be beneficial. At a minimum, doing this and waiting a few seconds for a filesystem flush will minimize the risk of damage, whereas pulling the drive while recording is still happening is almost certain to result in filesystem damage. This is true whether FAT or ext4fs is in use. I don't know offhand which filesystem would be more susceptible to damage in this type of situation.

 

[Msjulie]

Hmm, pressing and holding the camera until if puffs away (that's what it reminds me off) hasn't yielded errors for me.. well least not that my Mac cares to report

I agree the UI provided is somewhat obscure..

 

[guitarman]

I can confirm that EXT4 format works for dashcam and sentry mode. This is on FW 2019.32.12.2.

On the right front USB port, I have a USB hub -- Onvian 3 Port Ultra-Mini USB Data Hub, High Speed USB Splitter Hub. Connected to that are 2 microSD-to-USB adapters. One SD card is 128GB formatted as EXT4 for the dashcam/sentry mode. The other SD card is 200GB and formatted as EXT4 for Music. Both work exceptionally well. The music SD card holds FLAC and MP3s and will scan/load almost 150GB worth of music in less than 30 seconds.

 

[Jedi2155]

My biggest problem with Ext4 format is that i can't just plug it in my phone and read directly from it (despite it being Android/Linux).

 

[theredviper]

Any issues splitting a USB into EXT4 for music and FAT32 for sentry? I currently do this with FAT32 on both, but since v10 I've been experiencing some very brief audio dropouts, and I'm wondering if EXT4 will be better for performance on the music side. Seems to be from what I'm reading.

 

[sduck]

Depends what you mean by USB - there are many different kinds of drives that can plug into USB - I've used a ssd partitioned into 2 sides, one fat32, one ext4, with no problems.

 

[theredviper]

Depends what you mean by USB - there are many different kinds of drives that can plug into USB - I've used a ssd partitioned into 2 sides, one fat32, one ext4, with no problems.

Just the USB key I use now, which is already multi-partitioned. I'm guessing it will function the same as the SSD. Can't hurt to try.

 

[guitarman]

I can confirm that EXT4 format works for dashcam and sentry mode. This is on FW 2019.32.12.2.

On the right front USB port, I have a USB hub -- Onvian 3 Port Ultra-Mini USB Data Hub, High Speed USB Splitter Hub. Connected to that are 2 microSD-to-USB adapters. One SD card is 128GB formatted as EXT4 for the dashcam/sentry mode. The other SD card is 200GB and formatted as EXT4 for Music. Both work exceptionally well. The music SD card holds FLAC and MP3s and will scan/load almost 150GB worth of music in less than 30 seconds.

I wanted to update the statement above. Using EXT4 for dashcam was stable for a short while, but then an error occurred where Tesla said it it needed reformatting. However, it was mountable and readable in a Linux system. Using EXT4 filesystem within Tesla uses uid=1984 and when mounting, you cannot modify the files. I don't know the effect of changing this. I have since gone back to FAT32 and will do some more testing.

EXT4 for music still seems very stable and working well.