I had to get my son a glass of water around 4 this morning. As I'm walking throught the living room to the bedroom I notice that the fan on my 722 is on and working as if the 722 is on fire. Then all the lights on the front of the panel come on for a few seconds. Then the fan dies down. The whole time this was happening though, the receiver was cool to the touch. So I turn on the tv and 722 and after a few moments it comes on and I get the Acquiring signal picture on the screen as if the receiver resetted itself. So later this morning I go into the Diagnostics section and under Counters I see, 07) Fsck:1:5-30-08-4:00 AM. So I'm guessing this Fsck is what was going on but what does it stand for? Is it good or bad and what makes it happen, should I worry. Thanks.
What does Fsck in the Diagnostics menu mean?
- Thread starter fatmikla22
- Start date
- Latest activity Latest activity:
- Replies 17
- Views 6K
Why does it happen and how often does it happen. Your relpy makes it seem like it's a normal function.
I don't have a Dish box so I don't know how often they run it, but honestly it's not a function that runs all the time unless the file system reports inconsistencies. Maybe someone else here with a dish dvr can be of more use, but in the meantime, read up the Wiki on the fsck function
fsck - Wikipedia, the free encyclopedia
fsck - Wikipedia, the free encyclopedia
It is a normal function in Linux (the version of Unix that runs on the 622/722) to check the disk every so many reboots. I believe it is often normal for the DVR to reboot itself every so often after the early morning updates. So, it is normal for the box to check the disk periodically.
It is actually a good thing, by the way. fsck will normally automatically correct any inconsistancies it finds, so little problems don't grow into big ones.
More like chkdisk, less like scandisk.
Like Chkdisk, fsck verifies directory structures and file linkages, and will 'fix' things if it finds an inconsitancy. A bad-block scanner, like scandisk, is generally not needed on Unix systems since the filesystem driver itself checks the state of the disk block in real time and will map it out of use and put the data somewhere else if it discovers a bad block.
It was preferred by Dish method of squashing program bugs like memory leak, resources locks, etc.
Instead of debugging and fixing own code, they prefer to force reboot the device each 24 hours at customer side.
Instead of debugging and fixing own code, they prefer to force reboot the device each 24 hours at customer side.
As long as the file system gets a clean shutdown, ext3fs (the standard linux file system) will not need any checking. It is a journaled fs, and the journal gets replayed for an fsck.
Most reasonably modern file systems are journaled.
Cheers,
fsck is not normal for modern journaled file systems. If they truly do fsck daily; that's symptomatic of a greater issue.
Cheers,
Cheers,
I've actually had to run fsck on ext3 file systems that went read-only because of inconsistancies that occured *while* the system was running. I've had to do the same on ufs and even vxfs.
No file system is perfect - there are always corner cases that will rise up and bite you in the A$$
From what I've seen, fsck is not run daily. At least, not on the 622. I'm not at home right now, so I can't tell you when the last time mine ran it, but it was a while ago. As I said in an earlier post, almost *every* Linux distribution runs fsck on a periodic basis based on the number of boots since the *last* time fsck was run.
This is a very normal and good function. I had the feature turned off on my 625 (can NOT turn it off in the ViP boxes) and I can say that the 625 encountered anomalies for several weeks. Then I turned the feature back on, set for a good reboot time, and the 625 was solid from then on.
I won't ask where you came up with that. It's not true. A journal helps in recovery, but it is not the end-all. I'm sure you know that an EXT3 filesystem is nothing more than an EXT2 filesystem with a journal attached. When you fun fsck, you are checking the underlying EXT2, not the journal. You can actually take an EXT3, drop the journal, and mount and use it as an EXT2. Or you can add a journal to an EXT2 after creation and mount the result as EXT3.
I'm more inclined to agree with you on this one. However, Dish may simply have it setup to force fsck on every reboot. That would be overkill, but if this is the case it doesn't necessarily indicate a "greater issue", other than Dish programmers don't really know what they're doing. Normally you run fsck every XXX mounts of a filesystem, typically every 20 or 30. Most systems set this up for you automatically when you create the filesystem. Even on journaled filesystems.
O.P. - The fact that you're seen fsck running is because Dish is telling it to run. It doesn't just kick off on it's own because a problem has occurred. The exception being that if the problem was so bad the system actually crashed, on the next reboot an unclean filesystem dismount would be detected and fsck might automatically be run in that case. After a crash you WANT to run fsck - that's a good thing. The crash is bad, but fsck is the hero here, not the villain. Normally, fsck is TOLD to run at whatever interval by Dish programmers (probably on reboot or every XXX number of filesystem mounts), and then it MAY find a problem and attempt to correct it. Now, if you see fsck running and DETECTING ERRORS, that's a different story. But just running, not a problem.
The linux based Dish boxes reboot every night, linux systems normally run fsck on every boot. On a clean reboot fsck will see that the disk was unmounted properly and does not need to be scanned. If the drive wasn't shutdown clean then it will be scanned, either way fsck did run. It is also possibly to configure fsck to scan the drive if it has been mounted without scanning after X number of times.
Just to reiterate, running fsck daily is fine and doesn't mean anything. If it finds and corrects problems every time it runs, then yes, that's a problem.
Yeah, they didn't force a reboot nightly with older receivers. I had a 522 for a couple of years and it didn't reboot every night when it did a guide update, though I did force a reboot once a week and I usually didn't have the same problems that many others had.
