After deleting a bunch of shows off my hard drive I've noticed that I have had less drop outs and the fan hasn't been running near as much as it has in the past... wonder if anyone else has experienced anything like that with the hard drive not being near capacity??
Noticed something interesting...
- Thread starter itsonthedish
- Start date
- Latest activity Latest activity:
- Replies 16
- Views 3K
I did notice thatr with my 508 and now with my 721 that if you fill the hard drive more than halfway, it starts to affect the functionality.
I had it blink out on me twice when I recorded nascar last weekend. (I let it play an hour then I watch to zoom through the commercials.)
I had it blink out on me twice when I recorded nascar last weekend. (I let it play an hour then I watch to zoom through the commercials.)
Could have something to do with fragmentation.... I wonder if they do any defragging of the drive during routine mantenance? Or to defrag it, you have to delete everything? I hope that if you do this, that the system is smart enough to drop the files in perfect order and not place them back fragmented. I wish there was a manual option I don't mind my system being un-available for a couple of hours while I'm asleep.
I have been getting more and more dropouts recently with my average free space being 9 hours. I was hoping that a software update would fix the problem as I am hesitant to capture what I want to keep if there are gonna be glitches... Sort of a catch-22 if it is because of fragmentation.
I have been getting more and more dropouts recently with my average free space being 9 hours. I was hoping that a software update would fix the problem as I am hesitant to capture what I want to keep if there are gonna be glitches... Sort of a catch-22 if it is because of fragmentation.
The more stuff you have on a drive, the harder it makes it to defragment. To put the pieces back together (next to one another), the OS has to move the data to clear spots in order to free up bigger spots. Then it moves the pieces back to fill up this large opening.
These boxes run Linux though and use the XFS filesystem. To my knowledge, they DO NOT REQUIRE defragging !
These boxes run Linux though and use the XFS filesystem. To my knowledge, they DO NOT REQUIRE defragging !
I have heard this before. Not with DVR's but with XFS in general. Can you explain why it doesn't need defragging? How can there be no fragments when files are deleted in random order? Or is it's retrieval algorithm so good that fragmentation isn't an issue?hall said:
I actually read that filesystems like ext2/3, ReiserFS, and so on require little to no defragging. It's simply in their design.... I certainly can't explain the technical details of it. 
I did find something's from Googling:
http://twiki.org/cgi-bin/view/Wikilearn/LinuxFilesystems
(see the table and it lists which filesystems require defragging, among other info)
http://www.orafaq.net/maillist/oracle-l/2004/02/09/0958.htm
http://www.ece.ualberta.ca/~akodian/elug/msg04377.html
Here's an interesting statement, straight from the horse's mouth (SGI, the developers of XFS):
http://oss.sgi.com/projects/xfs/faq.html#fullfs
I did find something's from Googling:
http://twiki.org/cgi-bin/view/Wikilearn/LinuxFilesystems
(see the table and it lists which filesystems require defragging, among other info)
http://www.orafaq.net/maillist/oracle-l/2004/02/09/0958.htm
"How is it that there are no "defrag" utilities for UNIX?"
Well, unix file systems are usually block oriented and not extent oriented. Similarly to LMT, it is much harder to fragment block oriented file systems. The file systems that do have extents, like JFS or XFS are not used so much that someone would bother to write a defragmenter.
Well, unix file systems are usually block oriented and not extent oriented. Similarly to LMT, it is much harder to fragment block oriented file systems. The file systems that do have extents, like JFS or XFS are not used so much that someone would bother to write a defragmenter.
http://www.ece.ualberta.ca/~akodian/elug/msg04377.html
Dear god, DON'T defrag a linux filesystem! The only defrag tools are experimental, they're more likely to corrupt your drive than they are to make anything go faster.
Here's an interesting statement, straight from the horse's mouth (SGI, the developers of XFS):
http://oss.sgi.com/projects/xfs/faq.html#fullfs
Q: Does the filesystem slow down when it is nearly full?
XFS will slow down doing allocations when it is really full, you are no where near full untill 99.x%. Basically XFS chops the filesystem into allocation groups (1 to 4 Gbytes each), free space is managed independently in each of these. The slowdown happens when you have to scan through lots of allocation groups looking for space to extend a file.
XFS will slow down doing allocations when it is really full, you are no where near full untill 99.x%. Basically XFS chops the filesystem into allocation groups (1 to 4 Gbytes each), free space is managed independently in each of these. The slowdown happens when you have to scan through lots of allocation groups looking for space to extend a file.
There's nothing new under the sun.
Sounds to me like XFS works just like IBM VSAM circa 1980 or so
Sounds to me like XFS works just like IBM VSAM circa 1980 or so
Thanks to Micro$oft and all the problems around Win9x based OSes, Defrag is something us geeks think about often when we see poor system performance. If E* truly runs a flavor of Linux or Unix then the need to defrag a disk goes down alot. (as is noted by hall)
One idea that has come to my mind about the choppy DVR play back problems is the swapfile may not be large enough. However that point quickly falls apart when one event is "DVR'ed" and there is choppy playback, or even worse-choppy playback of a five minute pause.
After a fair ammount of thought on the subject, and fighting with my 522, I am left with one conclusion. The software that handles the playback of video is written poorly and is unable to do the job that is required of it. I feel there is little that we can do short of raising hell with E* til they get a more stable, less leaky, codebase to resolve the problem
but thats me...
RiGGs
One idea that has come to my mind about the choppy DVR play back problems is the swapfile may not be large enough. However that point quickly falls apart when one event is "DVR'ed" and there is choppy playback, or even worse-choppy playback of a five minute pause.
After a fair ammount of thought on the subject, and fighting with my 522, I am left with one conclusion. The software that handles the playback of video is written poorly and is unable to do the job that is required of it. I feel there is little that we can do short of raising hell with E* til they get a more stable, less leaky, codebase to resolve the problem
but thats me...
RiGGs
Granted, I'm no expert on Linux file systems, but I am a software developer, and I've never heard of a file system (block-based or otherwise) that doesn't become fragmented over time and use. I'm not clear on how the author of your first link comes to the conclusion that defragging is not necessary for XFS or the others listed.
I did a quick Google search and, in fact, there is a defragger for XFS called xfs_fsr, which "[compacts] or otherwise [improves] the layout of the file extents."
I have wondered what defragging strategy is used on the 522. I hope the answer isn't "none".
I did a quick Google search and, in fact, there is a defragger for XFS called xfs_fsr, which "[compacts] or otherwise [improves] the layout of the file extents."
I have wondered what defragging strategy is used on the 522. I hope the answer isn't "none".
Actually, considerig normal usage patterns, even if fragmentation was an issue with XFS (which is a different discussion), it would not be that much of a factor with a DVR.
Basically, most of the time, we're using space in 30 minute chunks. So when an old show gets deleted, it leaves a hole that's "close" to the correct size for reuse. Of course, due to bandwidth differences, it's not 100%, but overall I don't think it's a problem.
BTW, My 921's 250GB HDD is full almost all the time, and I've never had a problem that I can even begin to blame the filesystem for.
The only anomaly is that when deleting things, sometimes I get "more" space back than the program "used". This might be due to space at the end of the deleted show that was ignored (maybe because it was smaller than the base allocation unit) now being returned to free space. That's all speculation of course, but I can see it.
This hypothesis is in addition to the normal "unevenness" of space usage due to bandwidth usage differences (some shows will use more space than others for several reasons - transmit allocation, motion levels, and of course, HD shows take 7 times as much space as SD).
Basically, most of the time, we're using space in 30 minute chunks. So when an old show gets deleted, it leaves a hole that's "close" to the correct size for reuse. Of course, due to bandwidth differences, it's not 100%, but overall I don't think it's a problem.
BTW, My 921's 250GB HDD is full almost all the time, and I've never had a problem that I can even begin to blame the filesystem for.
The only anomaly is that when deleting things, sometimes I get "more" space back than the program "used". This might be due to space at the end of the deleted show that was ignored (maybe because it was smaller than the base allocation unit) now being returned to free space. That's all speculation of course, but I can see it.
This hypothesis is in addition to the normal "unevenness" of space usage due to bandwidth usage differences (some shows will use more space than others for several reasons - transmit allocation, motion levels, and of course, HD shows take 7 times as much space as SD).
Well, it may be a little optimistic to think that most of the available "slots" are the space equivalent of a multiple of 30 minutes of video. Even if compression factors are ruled out, you still get fragmentation given that you sometimes record partial shows that are not an even increment of 30 minutes. Plus, the 522 has that default "lead in" and "trail off" time of 1 and 3 minutes, respectively for timer events. The effects of these things are amplified over time if there is no defragmentation.
That said, I totally agree that this may have nothing to do with the A/V freezing and dropouts people have seen.
That said, I totally agree that this may have nothing to do with the A/V freezing and dropouts people have seen.
Hardrive nightly diagnostics?
So is the system basically running a scandisk then (and not a defrag) everytime it runs the nightly harddrive diagnostics?
My 522 just last night informed me that errors were detected during last nights scan and the hardrive would have to be cleaned, losing all of my recordings within 7 days or it would do it for me...
What causes these so called errors and why does the entire filesystem have to be redone to fix the problem?
I have had the 522 for just over a month now. We have had numerous searching for satellite issues, and several audio dropouts/color fades during playback of events, but this is getting ridiculous.
--Dudleydog73
So is the system basically running a scandisk then (and not a defrag) everytime it runs the nightly harddrive diagnostics?
My 522 just last night informed me that errors were detected during last nights scan and the hardrive would have to be cleaned, losing all of my recordings within 7 days or it would do it for me...
What causes these so called errors and why does the entire filesystem have to be redone to fix the problem?
I have had the 522 for just over a month now. We have had numerous searching for satellite issues, and several audio dropouts/color fades during playback of events, but this is getting ridiculous.
--Dudleydog73
I saw a post on one of the Yahoo! Dish-related groups from someone who pulled the HDD out of their 522 and connected it to their Linux box. They mounted the drive and saw 3-4 partitions, one of which was a swapfile. I want to say in the 20gb range. The "system" or root partition was rather small, which is understandable, and the remainder was strictly storage.SimpleSimon said:riggs - good post, but no swapfile in these boxes
Well, I certainly could be wrong, but I don't see how a real-time video box could run while doing swapping - for anything but maybe very auxiliary functions - like games.
And a 20GB swapfile is just "wrong" - way huge - especially for Linux.
So, lemme speculate: Maybe that's the space dedicated for VOD or the skipback buffer or such.
And a 20GB swapfile is just "wrong" - way huge - especially for Linux.
So, lemme speculate: Maybe that's the space dedicated for VOD or the skipback buffer or such.
