Disk initialisation order when waking up from Deep Standby

[Mickkie]

I've posted in the past about a problem with waking up from Deep Standby for a recording and not going back into Standby, but this problem I report here gave me a fright. :(

I flashed my Mut@ant with OpenViX 5.2.001 and rebooted, restored settings, installed e2iplayer which was not reinstalled as part of restoring plugins and thought all was well done.

Then thought of testing to see if waking up from Deep Standby worked as it used to some versions ago, so put it into Deep Standby and a couple of hours later when a recording was meant to have started I went back to it to see if it had succeeded to go into Standby, while it was recording a program. I was confronted with this error message:

Creating hardlink to timeshift failed!
The filesystem on your Timeshift-Device does not support hard links.
Make sure it is formatted in EXT2 or EXT3.
[Errno 1] Operation not permitted.
I checked the settings to make sure Timeshift was assigned to use the /media/hdd/ drive and not a USB stick I have plugged in for PICONS. The settings were all correct. I looked at the list of recorded programs and then I panicked because all the recordings were gone, except for the recording currently in progress. :eek:

I also checked the Recordings settings to see they were assigned to the /media/hdd/ drive as they should be and this setting was also correct.

I stopped the recording and deleted the current timer, unmounted both spinning disk and USB stick and run fsck on both of them. The USB had a dirty bit set. I rebooted and all my recordings were restored. Listing the contents of the USB drive revealed it had been initialised as /dev/sda1 instead of the HDD and therefore it was being used for recordings and timeshift.

Any idea why this happened and how I can avoid this happening in the future? I am avoiding placing the Mut@nt into Deep Standby for now.

[abu baniaz]

Initialisation = format

Your issue is not initialisation, but mounting. Go to Mount Manager and ensure mounts are as you need.

[adm]

I've seen this type of problem a couple of times in the past immediately after performing an image update where a USB gets mounted on the reboot but not the hard disk. As a result the box attempts to put the timeshift and/or recordings on the stick (which has insufficient capacity). A cold reboot (switching off at the mains for 60 seconds) after an image update has always restored correct operation with respect to mounting the hard disk. Subsequent daily entry into deep standby has not shown the problem again.

[Mickkie]

@abu baniaz: Apologies for not using the correct nomenclature. I meant when the MoBo starts probing devices and udev initialises them, they are not initialised in the correct order and therefore they are mounted incorrectly. Where is the "mount manager"?

@adm: I tried what you suggested. The same problem occurred:

Before I powered down:

# blkid | grep sd.1
/dev/sda1: UUID="e639994e-9466-471a-8c77-285b59d9ff13" TYPE="ext4" PARTLABEL="primary" PARTUUID="1483c56d-85ce-4de1-a0be-e216dcf9b3c4"
/dev/sdb1: LABEL="USB DISK" UUID="1043-0091" TYPE="vfat" PARTUUID="c3072e18-01"

After I powered up:

# blkid | grep sd.1
/dev/sda1: LABEL="USB DISK" UUID="1043-0091" TYPE="vfat" PARTUUID="c3072e18-01"
/dev/sdb1: UUID="e639994e-9466-471a-8c77-285b59d9ff13" TYPE="ext4" PARTLABEL="primary" PARTUUID="1483c56d-85ce-4de1-a0be-e216dcf9b3c4"

This problem does not occur if I just reboot.

[twol]

Menu/setup/vix ——> Mountmanager

[Mickkie]

Thank you twol, I just came across it as I was checking which drive is used to save backups and images. Here is a screenshot of57551 what it shows, but this is not the order in which devices are mounted when the Mut@nt is woken up from a Deep Standby.

[abu baniaz]

IIRC, if you save the mount points in mount manager, the mount points use a different, more resilient method.

Please confirm you have "saved" while in mount manager.

May I ask why you need the USB stick and also in a non-linux file system.

[Huevos]

You are in the correct screen. Open each device in turn and save the settings.

[birdman]

Listing the contents of the USB drive revealed it had been initialised as /dev/sda1 instead of the HDD and therefore it was being used for recordings and timeshift.

Any idea why this happenedIt's an issue about which device responds first when the various communication buses are probed at boot time.
This can be random, and also dependent on any "extra" USB devices present at boot time.
The solution is to mount devices using their partition UUID, which is what will be set-up if you configure mount points in the Device/Mount Manager.

[Mickkie]

Thank you all for your replies. I've used the Mount Manager in the Vix menu to (re)confirm the devices were as shown and saved the results, rebooting each time as it asked me to do. I set the device into Deep Standby and when it woke up their order in which they were mounted was respected.

Interestingly, /etc/fstab shows the devices with their UUIDs:


/dev/mmcblk0p1 /boot auto defaults 1 1
rootfs / auto defaults 1 1
proc /proc proc defaults 0 0
devpts /dev/pts devpts mode=0620,gid=5 0 0
usbdevfs /proc/bus/usb usbdevfs noauto 0 0
tmpfs /var/volatile tmpfs defaults 0 0
/dev/mmcblk0p10 none swap defaults 0 0
UUID=e639994e-9466-471a-8c77-285b59d9ff13 /media/hdd auto defaults 0 0
UUID=1043-0091 /media/usb vfat defaults 0 0

@abu baniaz: I'm sure I read somewhere a USB stick is recommended for saving PICONS and for storing the EPG. I left it with a VFAT fs (as opposed to ext2) because this is what I use often to flash the Mut@nt with a new image and the various guides state the USB used for flashing should be formatted as VFAT.

[abu baniaz]

EPG is best on HDD.

I'd only use a separate flash drive for picons if it is a large picon set. Internal flash is fine. Anyway, your issue should be resolved now.

[bbbuk]

I use HDD for both EPG and picons without any issues :)

[Huevos]

I use HDD for both EPG and piconsPutting picons on the HDD means either the HDD is kept permanently awake, or the HDD has to spin up just to open the infobar. Either way, not something we would recommend.

The only benefit of putting picons on a USB drive is that it is easy to transport them from box to box.

[abu baniaz]

Or not having to reinstall after flashing

[Huevos]

Or not having to reinstall after flashingMine are on USB and not added from the feeds, but means the picons go out of date over time.

[bbbuk]

Putting picons on the HDD means either the HDD is kept permanently awake, or the HDD has to spin up just to open the infobar. Either way, not something we would recommend.Is this to avoid wear/tear on HDD because USB also suffers from wear/tear, MTBF, limited read/write cycles and potentially prone to NAND failure from irregular USB voltage spikes. If it's purely for speed, then I agree USB would likely win over HDD if HDD did have to spin-up first (ie not already in use by likes of timeshift).

I guess it really depends on individual circumstances/setup...

Anyone who has timeshift enabled then they are already using HDD so no difference and in fact you would be putting undue stress/wear/tear on USB stick for no reason imho. I've had my HDD in my solo2 for many years and timeshift and record a lot without an issue with HDD.

[Huevos]

I don't have PTS enabled. In that configuration there is a big pause every time the infobar is invoked.

[birdman]

Is this to avoid wear/tear on HDD because USB also suffers from wear/tear, It's to stop the disk being spun up for any item which displays a picon.
USB sticks don't suffer wear&tear when being read (which is all this needs) and do not need to spin up.

[bbbuk]

It's to stop the disk being spun up for any item which displays a picon.
USB sticks don't suffer wear&tear when being read (which is all this needs) and do not need to spin up.I read somewhere that NAND chips in USB do suffer from wear even just reading as it's approximately equivalent to 10 write cycles = 1 read cycle. This affects some type of NAND chips more than others.

Ultimately, as I said, it depends on whether someone has timeshift enabled because if they do then they're already using HDD so why put wear/tear on USB as well as HDD when no need. I've used HDD for years without an issue that includes timeshift and recording.

If not using timeshift, then yes there is an advantage to using USB (speed of displaying picons due to no spin-up time).

[birdman]

I read somewhere that NAND chips in USB do suffer from wear even just reading as it's approximately equivalent to 10 write cycles = 1 read cycle. This affects some type of NAND chips more than others.Once it has been read it will be cached in memory.

[ccs]

Once it has been read it will be cached in memory.
Won't that happen with an HD as well, or is there a re-read of the directory, say, to check for any changes?

[twol]

I read somewhere that NAND chips in USB do suffer from wear even just reading as it's approximately equivalent to 10 write cycles = 1 read cycle. This affects some type of NAND chips more than others.

Ultimately, as I said, it depends on whether someone has timeshift enabled because if they do then they're already using HDD so why put wear/tear on USB as well as HDD when no need. I've used HDD for years without an issue that includes timeshift and recording.

If not using timeshift, then yes there is an advantage to using USB (speed of displaying picons due to no spin-up time).

... but on modern chips you are looking at cycles in the millions before hitting this issue..... whereas with HDD (although they are in general better ... you have latency, seek issues and wear through head/media issues).
So for recording and timeshift - HDD is fine.... but for events like Picons , settings backup, image backups ... usb is perhaps preferable, especially as its moveable.
Like everything its a case of getting the best out of the technology

[bbbuk]

... but on modern chips you are looking at cycles in the millions before hitting this issue..... whereas with HDD (although they are in general better ... you have latency, seek issues and wear through head/media issues).USB suffers from all of these issues (except seek).

So for recording and timeshift - HDD is fine.... but for events like Picons , settings backup, image backups ... usb is perhaps preferable, especially as its moveable.
Like everything its a case of getting the best out of the technologyThis is where we disagree. You're effectively stating that even when using timeshift, it's still better to use a separate USB for storing picons?

What is advantage of this because if using timeshift, you already have HDD upto correct spin speed anyhow and working so as well wear/tear on HDD, this also means then extra wear/tear of USB as well as HDD.


Once it has been read it will be cached in memory.As mentioned by @ccs, if it's cached then surely that equally applies to HDD as well if cached by box in memory and therefore the WoS guidance that USB is recommended for picons even if using HDD (due to timeshift), has little bearing other than add to wear/tear of USB as well as HDD.

[twol]

I would suggest this post is closed before it goes even further off topic

[birdman]

Won't that happen with an HD as well, or is there a re-read of the directory, say, to check for any changes?Well, yes it will - but the issue with using the HDD is spin-up time. As you say, if you're using timeshift you'll have it permanently on (using power) anyway.