Why is sentry mode "unsafely removing" hard drives?

[mj3ngr]

I find sentry mode recording to be somewhat unreliable because the car seems to keep corrupting hard drives by unmounting them without "safely removing" them (even though they stay plugged in), thus can't save the recorded videos.

Why is it doing that? Is there something I might be doing wrong? Is there something I can do to prevent it?

I usually don't notice when it's like this because my only indication is that the dashcam button is missing on the top right of the screen. Is there some way to get notified sooner?

I use a 500 GB Samsung T5 SSD, formatted with ext4.

When I do notice, I take the drive inside and plug it into my laptop (Linux). First, from auto-mounting, I get "Error mounting /dev/sda1 at /media/mej/TeslaCam2: can't read superblock on /dev/sda1."

It's simple to "fix" the drive: `sudo fsck.ext4 -v /dev/sda1` always does the trick, usually producing output like the following:

```
e2fsck 1.44.1 (24-Mar-2018)
TeslaCam2: recovering journal
JBD2: Invalid checksum recovering block 26 in log
Journal checksum error found in TeslaCam2
TeslaCam2 was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong (117353706, counted=116797326).
Fix<y>? yes
Free inodes count wrong (30531276, counted=30531205).
Fix<y>? yes

TeslaCam2: ***** FILE SYSTEM WAS MODIFIED *****

379 inodes used (0.00%, out of 30531584)
330 non-contiguous files (87.1%)
1 non-contiguous directory (0.3%)
# of inodes with ind/dind/tind blocks: 0/0/0
Extent depth histogram: 370/1
5298682 blocks used (4.34%, out of 122096008)
0 bad blocks
1 large file

357 regular files
13 directories
0 character device files
0 block device files
0 fifos
0 links
0 symbolic links (0 fast symbolic links)
0 sockets
------------
370 files
```

Which seems to indicate that it was unplugged or unmounted without "safely removing"

This has happened twice this week, both times within a day of me fixing the previously corrupted drive.

It feels like if anything happens to my car, I'm likely to not have a recording of it making the feature mostly useless.

My semi-workaround for now is to keep two SSDs so that as soon as I notice one corrupted, I can go ahead and swap it out without needing to get to a computer to fix it.

 

[linux-works]

I have not seen this for a few software versions, since the 40's or 50's, I think.

it has been reported that tesla is not unmounting the drive gracefully when it sleeps. it seems to have gotton better with current software.

there was a rasp pi project that emulated usb storage and protected against ungraceful dismounts. otoh, when I tried using that solution, the pi, itself, was often not fast enough to keep the tesla happy.

 

[mj3ngr]

Could I prevent it from sleeping? This seems to have happened more often in the past 2 weeks, but I've also not been keeping my charge as high the past couple of weeks since I've been on vacation and haven't been charging at work (no home charging)

 

[eli_]

Could I prevent it from sleeping? This seems to have happened more often in the past 2 weeks, but I've also not been keeping my charge as high the past couple of weeks since I've been on vacation and haven't been charging at work (no home charging)

If sentry mode is active then the car stays awake but you'll lose some charge, like 1% every couple hours.

 

[SMAlset]

@mj3ngr not clear from what you wrote but is this doing it by itself or are you not properly shutting down TeslaCam when you go to remove the drive? In case the latter you have to briefly depress and hold the camera icon (it sends out a screen "wave" indicating it is shutting down) and the red light on the camera icon will turn off. Then it's safe to remove the drive. The instructions for doing this are in the Manual (Page 72 of the 10/30/19 version). See instruction for "Paused".