[VU+ Duo] what is swapfile_xmltv file

[brdbch]

I have this 16 MB swapfile_xmltv sitting in the root directory, and updated every day.
I supposed it belongs to the EPG XMLTV-Importer feature.
Is there a way to move it elsewhere, like on the hdd or on an USB key?

 

[Rob van der Does]

The 'swapfile_xmltv' is a new feature.
During the import and parsing of XMLTV-data the box needs temporarily much memory. If memory is low at that moment, this SWAP-file will be created to overcome that and to prevent an Enigma2 restart.
And indeed, as you have observed, the SWAP-file is left behind. That's simply because of the fact that a SWAP-file that's in use, can't be deleted.

And to your question: no, it can't be placed elsewhere. But being only small, it doesn't harm you, does it?

 

[brdbch]

It's not that small. On my box this is 16% of the flash space.
Running out of flash space is also a good way to crash the box.
Also i dont see the need for it since i already have a swapfile configured.
The strange thing is that this file is not even activated as a swapfile, since it does not show up in /proc/swaps.

 

[Larry-G]

The first thing you should do then is disable the swap file you put in place your self as this can and does slow the box down considerably. The XMLTV swap file as rob pointed out is needed as the process of importing all that data in one go can easily overwhelm the box. As for it not being shown as active you are correct as it's only needed during a XMLTV import.

 

[Rob van der Does]

Ahh, it's in your flash! That indeed is strange.

You say you have already a SWAP-file enabled: on which device is that?

Can you give me the results of

df -h

PS: Why do you use a SWAP? Unless you have a very special configuration, using SWAP is not a good idea and will only result is (s)low performance. Which box do you have?

 

[brdbch]

I am using a VU+ Duo.
I installed a 40GB Corsair F40 SSD (i found one for around 40£) as the internal sata device, and the hard drive on the Esata.
The SSD runs at 285Mb/s in read and 275Mb/s in write operations, which is probably far more efficient than the internal flash.
I stored swap, epg, picons and timeshift files on it, and it really speeds up things.
Zapping is much faster, as well as graphical EPG display.

This the output of the df -h
Filesystem Size Used Available Use% Mounted on
ubi0:rootfs 101.8M 64.2M 37.6M 63% /
tmpfs 64.0K 4.0K 60.0K 6% /dev
/dev/sdb1 37.3G 1.2G 36.0G 3% /media/hdd
tmpfs 67.5M 872.0K 66.7M 1% /var/volatile
/dev/sda1 1.8T 592.7M 1.8T 0% /media/sda1
10.110.110.110:/files/more/records/ 5.4T 2.1T 3.0T 42% /media/net/archives

 

[Larry-G]

It's not a good idea to use a SSD on a receiver as it will degrade very fast.

 

[brdbch]

USB keys degrade rapidly. SSDs dont.
Writing 4GB/hour on a 40GB SSD gives a life expectancy of about 4000 days.

I am also very surprised about the statement that configuring a swapfile slows down operation.
Fisrt, it prevents crashes.
Second, Linux does not access swapfile (or very little) unless it is running short of main memory.
You can check how few accesses are done by doing regularly:

cat /proc/vmstat |grep pswp

The numbers barely change.

 

[Rob van der Does]

USB keys degrade rapidly. SSDs dont.
Writing 4GB/hour on a 40GB SSD gives a life expectancy of about 4000 days.

Wel, you forget one important item here: these numbers are valid if TRIM is being used. As far as I know that is not the case on STB's (or even on any Linux system).
Without TRIM degradation is a fast process......

I am also very surprised about the statement that configuring a swapfile slows down operation.
Fisrt, it prevents crashes.

Ah, but that is a totally different aspect. This is only the case when the system is suddenly in need of more memory then is available. During normal operations this should never be the case.
There are a few situations, where ViX automatically creates and activates a SWAP-file: during EPG-import (as the parsing process eats a lot of memory), when doing an online update and on making a backup image.

Second, Linux does not access swapfile (or very little) unless it is running short of main memory.
You can check how few accesses are done by doing regularly.

Enigma uses the SWAP as normal memory. When a box has just booted, available memory is high. During normal use, the amount will decrease (because Linux finds that memory not used = memory spilled). This is also the case when activating a SWAP: at first it is not/hardly being used, in the course of time more will be used.
Although I have no marks to prove that, I think that live memory is and will always remain the fastest memory available. And not only the speed of the memory itself counts: it's about the whole process that will take its time.

So for me the question remains: why would you (again: in normal operations) want to use a SWAP-file. As one thing is for sure: it can never make a process go any faster. And especially not on expensive, fast deteriorating SSD........

 

[brdbch]

Sorry, but Trim is standard in Linux since 2.6.33.
Also Trim does not have anything to do with life expentancy. It impacts only write speed (needs to erase before writing).

Why am i using always a swapfile in a Linux (or UNIX, or Windows) system? because it is suicide not to.
Any unexpected increase in memory requirement will cause a system crash.

Of course swap will not speed up operation and live memory is the fastest, but i'd rather have a slowdown than a crash.
As i said, you can easily watch the swap activity (number of IOs and number of pages) in /proc/vmstat.
You can also watch swap volume utilisation in /proc/swaps.

If you watch these metrics regularly, you can verify that your assesment about swap file activity is false.
The important thing to watch is pagin rate, which remains extremely low (under 1 a minute) independently of time,
unless it gets into saturation mode (where it would crash if no swap was configured).
Apart from that, creating a file (even if this is a swap file) in the root directory is considered as a bad programming practice.

 

[Rob van der Does]

Sorry, but Trim is standard in Linux since 2.6.33.

OK, didn't know that. Is it also available (and enabled) on our STB's?

Also Trim does not have anything to do with life expentancy. It impacts only write speed (needs to erase before writing).

Yes it is about live-expectancy: it prevents the same location to be written over and over again, while the rest is being left alone. See e.g.

http://modmyi.com/content/6603-how-enable-trim-your-mac-ssd-prolong-life-span.html

but much more information is available.

Why am i using always a swapfile in a Linux (or UNIX, or Windows) system? because it is suicide not to.
Any unexpected increase in memory requirement will cause a system crash.

LOL: how often does that happen (when using the box for the purposes it is intended for)? And it's not really a systemcrash: only Enigma2 will restart.
And for sure I would preventing an exceptional situation which only leads to an E2 restart not call 'preventing suicide". Especially not if the price to be paid is a slower box 24/7.
But of course: if that gives you a better feeling, please do so. After al it's about your box.

Apart from that, creating a file (even if this is a swap file) in the root directory is considered as a bad programming practice.

Not sure why you talk about the root. The root of the HDD or USB? No problem there IMHO.
But from your previous posting I take it that a SWAP-file was made in flash; if so that indeed is wrong. No idea why this happens for you; here the file is made on a device.
Maybe you can provide us debuglogs, showing the time of SWAP-creating?

 

[Rob van der Does]

Allow me two more remarks:

I stored swap, epg, picons and timeshift files on it, and it really speeds up things.
Zapping is much faster, as well as graphical EPG display.

So for me the question remains: why would you (again: in normal operations) want to use a SWAP-file. As one thing is for sure: it can never make a process go any faster. And especially not on expensive, fast deteriorating SSD........

Of course swap will not speed up operation and live memory is the fastest, but i'd rather have a slowdown than a crash.

So there we agree at last?

This the output of the df -h
Filesystem Size Used Available Use% Mounted on
ubi0:rootfs 101.8M 64.2M 37.6M 63% /

Well, since you're using only 64.2MB there for sure can't be a 16MB SWAP in flash.........

 

[brdbch]

Well, i have'nt yet seen any OS where activating swapfile would degrade performance, unless someone tampered with the Virtual Memory manager.
Where can i find the source files used to build this kernel?

About this swapfile_xmltv file, its getting stranger.
It was located in "/" directory, "ls -la" showed 16834560 bytes and the creation date changed every day.
However when deleting it, "df -h" did not show much difference. A bug somewhere?
Now, i turned off XMLTV_Importer, deleted swapfile_xmltv file, turned back on XMLTV_Importer, and i have not been able to locate this file anywhere.
Looks like its not created anymore.

 

[Rob van der Does]

Well, i have'nt yet seen any OS where activating swapfile would degrade performance,

Well, you have now, haven't you?
Please feel free to explain how a SWAP-file could possibly not slow down performance.

 

[brdbch]

Because, as long as the memory is not saturated, no IOs (or almost none) are performed between swapfile and main memory.
The system just writes out unneeded pages (like intialisations) to swap, therefore leaving more free main memory.
If the memory gets saturated, there is some paging-in and paging-out going on, therefore causing system slowdown (because the process has to wait for the IO completion to continue its execution).
But otherwise in the same situation, you would encounter a system or application crash.

Just watch vmstat output (columns si and so) to monitor paging space activity ("vmstat 10 1000").
You will see that it is almost always 0 activity.

You can also watch how much swap space has been usedin the swpd column.
You can see it almost never changes and remains quite low.