|
||||||||
Why is deleting so slow on the Foxsat? |
![]() |
|
|
Thread Tools | Search this Thread |
|
|
#1 |
|
Forum Member
Join Date: Feb 2004
Location: Sunny France (sometimes)
Posts: 1,019
|
Why is deleting so slow on the Foxsat?
It's not a problem I'm just curious really, why deleting a recording on the Foxsat HDR takes several seconds.
Normally file deletes on computers are pretty instantaneous since all that actually happens is that the directory entry is removed and the relevant disk space marked as free, the data itself still exists until it gets overwritten. The time it takes for the HDR to delete suggests that the data itself is getting deleted akin to a 'security wipe'. I can't think why this would be deemed to be necessary though, so is there another explanation? |
|
|
|
|
Please sign in or register to remove this advertisement.
|
|
|
#2 |
|
Forum Member
Join Date: Nov 2003
Location: Cradley, Halesowen, W.Mids
Posts: 1,047
|
Quote:
Normally file deletes on computers are pretty instantaneous since all that actually happens is that the directory entry is removed and the relevant disk space marked as free, the data itself still exists until it gets overwritten.
http://www.dataexpedition.com/~sbnob...lesystems.html As you will see deleting is far more complex than just removing a single entry from the file allocation table. |
|
|
|
|
|
#3 |
|
Forum Member
Join Date: Feb 2004
Location: Sunny France (sometimes)
Posts: 1,019
|
Quote:
The HDR uses the UNIX filesystem. Here is a link to explain how deleting works on this filesystem:-
http://www.dataexpedition.com/~sbnob...lesystems.html As you will see deleting is far more complex than just removing a single entry from the file allocation table. Thanks Richard, but I'm pretty familiar with Linux and ext3, and doing 'rm <file>' or even a whole directory of files is virtually instantaneous, unless, as I said, you choose to use something like 'shred' to actually wipe the data. |
|
|
|
|
|
#4 |
|
Forum Member
Join Date: Apr 2005
Location: Surrey, UK
Posts: 1,302
|
In the ext file system blocks that are deleted must be verified and while the HDR does this in the most economical way it does require the process to happen. Recordings are typically GB in size and as a result the CPU must spend time processing this function. It does this at low priority compared to other tasks so as reduce the impact on the broadcast reception side and as a result it takes time for a file to be deleted on the modest CPU. The product has a 400MHz MIPS single thread CPU to do all of it's functions including most of the graphics.
|
|
|
|
|
#5 |
|
Guest
Join Date: Apr 2004
Posts: 957
|
Quote:
In the ext file system blocks that are deleted must be verified ...
|
|
|
|
|
|
#6 |
|
Forum Member
Join Date: Apr 2005
Location: Surrey, UK
Posts: 1,302
|
To quote Andreas Dilger one of the developers of the ext3 file system: Quote:
In order to ensure that ext3 can safely resume an unlink after a crash, it actually zeros out the block pointers in the inode, whereas ext2 just marks these blocks as unused in the block bitmaps and marks the inode as "deleted" and leaves the block pointers alone.
This is the more intensive process that takes time.Bob |
|
|
|
|
#7 |
|
Forum Member
Join Date: Jul 2001
Posts: 2,644
|
Why cant it use the same system as Sky or even the old Humax 9200T when it was instant or at least deleted it in the background while you did something else ?
|
|
|
|
|
|
#8 |
|
Forum Member
Join Date: Jun 2010
Location: Perchede, France
Posts: 1,936
|
Quote:
Why cant it use the same system as Sky or even the old Humax 9200T when it was instant or at least deleted it in the background while you did something else ?
|
|
|
|
|
|
#9 |
|
Forum Member
Join Date: Jul 2001
Location: Brackley, UK
Posts: 16,657
|
Quote:
I think it does do it in the background - It's just that a flashing icon shows you it is happening. I think the only things you can't do is delete another file or start a file copy?
|
|
|
|
|
|
#10 |
|
Forum Member
Join Date: Jul 2001
Location: Brackley, UK
Posts: 16,657
|
Quote:
To quote Andreas Dilger one of the developers of the ext3 file system:
This is the more intensive process that takes time. Bob I prefer HPFS because it uses RLE in a B+Tree but also tries to keep FNodes close to the data they describe. It made recovering data a lot more reliable. Second best would be NTFS. I'm not keen on the centralised MFT but I like the way it encodes block allocations. I also love the way it's basically a superset of pretty much any other FS. About the only one we had to deal with that it couldn't mimic was AS400 - and that's not really a file system anyway. But the problem with NTFS is writing it. Reading is okay but there's so much you have to get right when you're writing to it
|
|
|
|
|
|
#11 |
|
Forum Member
Join Date: Oct 2004
Location: Buckingham
Posts: 28,537
|
Quote:
This is the more intensive process that takes time.
|
|
|
|
|
|
#12 |
|
Forum Member
Join Date: Apr 2005
Location: Surrey, UK
Posts: 1,302
|
Andrue,
I agree it isn't my favourite either. Apparently HQ have been doing some R&D on this subject as we head toward advanced next generation products. Bob |
|
|
|
|
#13 |
|
Forum Member
Join Date: Aug 2004
Location: Cambs.
Posts: 114
|
Apologies for resurrecting an old thread. I find deleting things using the media list a bit tedious and am wondering whether deleting via FTP may be a more efficient way of doing things. Given the info above, will deleting via FTP have the same effect as deleting via the media list? I would hate to have the programs disappear but the free space not released.
|
|
|
|
|
|
#14 |
|
Forum Member
Join Date: Jun 2008
Posts: 62
|
For comparison I have just done a delete of a 2G file on a slow computer with ext3. Took 4.5 seconds including 0.5 seconds CPU time. This on a 550MHz Pentium III.
So yes, large file deletes can take a little while. |
|
|
|
![]() |
|
All times are GMT. The time now is 23:58.


