Forum

Hi all,

First of all I would like to thank all the contributors for building this amazing package.

Problem description:
I used to utilize the xbian-copier from xbian-config to backup my xbian to an .img file, but after upgrading I am running into an error. I have tried also using and got the same. I get the error shown in the attached picture [attachment=329], the process ends after a few seconds and a file of zeros bytes is created in the destination folder.

Any thoughts? Is my filesystem corrupted?

Best,
Iraklis

Software
XBian version: XBian v1.0RC2
XBMC version: 13.1 Git:20140604-84725b0
Overclock settings: arm_freq=840, core_freq=275, sdram_freq=400, over_voltage=0

If it is an external drive, I would unplug it and run some tests on it.

Also what is it formatted as? FAT and sometimes FAT32 will cause problems.

Can you post the output of dmesg after a bad run if the above doesn't fix the issue.

that indeed looks like it can't prealocate needed space (either hitting limits on FAT or other dump filesystem without trunc support or ... i don't know).

(22nd Jun, 2014 08:50 AM)mk01 Wrote: [ -> ]that indeed looks like it can't prealocate needed space (either hitting limits on FAT or other dump filesystem without trunc support or ... i don't know).

IriDium and mk01,
Thank you for your reply.
I am using a cifs share mount to backup. I can access the share mount with rw access from xbian where there is plenty of disk space. The fstab entry is:

The dmesg that I get after running the command is the following:

What I don't understand is that I used to perform successful backups and somehow after a couple of months it stopped working.

Any other thoughts? How can I check percolated needed space?

Best,
JIK

---

(22nd Jun, 2014 06:11 PM)jyviko Wrote: [ -> ]

(22nd Jun, 2014 08:50 AM)mk01 Wrote: [ -> ]that indeed looks like it can't prealocate needed space (either hitting limits on FAT or other dump filesystem without trunc support or ... i don't know).

IriDium and mk01,
Thank you for your reply.
I am using a cifs share mount to backup. I can access the share mount with rw access from xbian where there is plenty of disk space. The fstab entry is:

Code:

//192.168.1.109/OpenShare/Backup/xbian  /media/backup  cifs  guest,uid=1000,iocharset=utf8  0  0

The dmesg that I get after running the command is the following:

Code:

btrfs: device label xbian-beta2 devid 1 transid 29377 /dev/mmcblk0p2

What I don't understand is that I used to perform successful backups and somehow after a couple of months it stopped working.

Any other thoughts? How can I check percolated needed space?

Best,
JIK

UPDATE:
I have just changed the fstab and replaced "guest" with a cfis user that has full access, using the following entry:

After remounting, I tried once more and although I am getting the same result I got a more detailed error message as shown in the attached image ([attachment=330]).

I have checked the dmesg and I now get the following:

Any ideas?

JIK<

@jyviko

if you get loop module loaded, that means space prealocation on created empty file is ok.

there are two options when looking at your new screen shot. the error is displaying block device /dev/mapper/p1. but it should have been /dev/mapper/loopXp1 (where X is 0-9). two reasons are coming to my mind:

1) bug of some kind causing not proper detection of used loop device - be sure you run last available xbian-package-config-shell which is 2.1.7-5 at STABLE repo.
2) cifs doesn't support all fs ioctl calls as required by loop and mapper modules.

for the 2) you could check manually like this:


if still ok, create partitions on that loop device and try to format them :

(22nd Jun, 2014 09:22 PM)mk01 Wrote: [ -> ]@jyviko

if you get loop module loaded, that means space prealocation on created empty file is ok.

there are two options when looking at your new screen shot. the error is displaying block device /dev/mapper/p1. but it should have been /dev/mapper/loopXp1 (where X is 0-9). two reasons are coming to my mind:

1) bug of some kind causing not proper detection of used loop device - be sure you run last available xbian-package-config-shell which is 2.1.7-5 at STABLE repo.
2) cifs doesn't support all fs ioctl calls as required by loop and mapper modules.

for the 2) you could check manually like this:

Code:

sudo -i
touch /media/backup/TEST.img
truncate -s 5G /media/backup/TEST.img <<<< let's test the 4GB limit per file (if prealocation is fully supported this should take no longer than few seconds (1-10). after that, with ls -lah /media/backup/TEST.img should read file size of 5GB

modprobe loop
losetup -f      <<< will just show first free loop device to use remember the name

losetup /dev/loopX /media/backup/TEST.img     <<<< /dev/loopX is actual loop as returned by "losetup -f"

if still ok, create partitions on that loop device and try to format them :

Code:

losetup -d /dev/loopX
fdisk  /media/backup/TEST.img <<<<< do on your own, create any two partitions. save par table.


kpartx -av /media/backup/TEST.img    <<<< that actual command will reuse loopX again, but will map them through mapper to /dev/mapper/loopXp1 and p2.

mkfs.vfat /dev/mapper/loopXp1
mkfs.btrfs /dev/mapper/loopXp2

Hi mk01,

First of all I had upgraded the version of xbian-package-config-shell to 2.1.7-5 from 2.1.7-4.
Then I tried what you suggested and I was able to create a 5Gb and then I successfully created the partitions and formatted them. When looking inside /dev/mapper I can see two loop1p1 and loop1p2. It seems that I am able to create those properly.
I tried once more with the xbiancopier and I cannot see loop device inside /dev/mapper. Maybe the script is somewhere broken?

Thank you for your support!

Best,
JIK

somewhere around 2.1.7-3 or -4 I was changing the way how .img size is auto-calculated. maybe that broke something. although I tested without issues for some scenarios.

let's try with manually specified img size, then the new calculation is not used and we will see if this is the problem. (also if you can report back - how big is the .img file after the process fails - when started via xbian-config as before)?


will try to create 2G img without auto calculation.

(22nd Jun, 2014 10:08 PM)mk01 Wrote: [ -> ]somewhere around 2.1.7-3 or -4 I was changing the way how .img size is auto-calculated. maybe that broke something. although I tested without issues for some scenarios.

let's try with manually specified img size, then the new calculation is not used and we will see if this is the problem. (also if you can report back - how big is the .img file after the process fails - when started via xbian-config as before)?

Code:

sudo -i
btrfs-auto-snapshot xbiancopy --size 2G --img /dev/root /media/backup/TEST.img

will try to create 2G img without auto calculation.

@mk01
This worked and the process moved on. The only problem is that it seems that I have a corrupted folder and I get "NFS Stale File Handle" (which is another issue). Tried to delete it with no luck. I am guessing that I cannot avoid reinstalling xbian from scratch Too bad I cannot backup first.
Is there a way that I can make a clean snapshot excluding that offensive folder and continue from there?

Best,
JIK

@jyviko

NFS Stale Handle should be caused when snapshot is created, it is being send with btrfs send command but the data are not yet on filesystem itself.

That's why btrfs fi sync was added after each btrfs sub snap operation. Strange is that now fresh docs are proposing standard "sync" instead.

open /usr/sbin/btrfs-auto-snapshot in any editor (as root) and go searching for "btrfs fi sync". first relevant should be around line 650+. feel free to update the code similar as you see there so try adding after each "btrfs fi sync" one "sync", like this:


it will be there maybe on two different places (where "sub snap" operation will be found - although the risky ones should be just those where "btrfs send" follows on the snapshot we just created).

please report back.

still, we have to fix that autosize calculation anyhow. I will try to reproduce.

---

btw: this is not any rocket science and if you consider you setup important, you can go around those steps manually (what will slow down tempo of transactions and you could be successful). manually simply means like this. also for the poor slow RPI as last resort I would prefer plain partition as destination, not .img file going through loop & mapper etc.
let;s say you have USB stick a /dev/sda1.

and of course iterate the second block for "root" and "modules". the /dev/sda1 filesystem should be bootable the way as your source - meaning rootflags=subvol=root/@,....... root=/dev/sda1 rootfstype=btrfs

@mk01

Hi, thank you for your reply. I have changed line 657 and added && sync as follows:
I didn't find another line that has both "btrfs sub snap" and "btrfs fi sync". Should I go and add "&& sync" to all other lines?

I ran again the xbiancopier and I am still getting the NFS Stale Handle.
My guess is that the problem derives from an earlier snapshot and it carried on. I had isolated the problem before by renaming that specific folder and copying a working version. It is the following folder "/usr/share/zoneinfo.old/posix/America" that contains the corrupted files. I cannot even stat them.

Any idea would be appreciated.

JIK<

(25th Jun, 2014 05:27 AM)jyviko Wrote: [ -> ]I ran again the xbiancopier and I am still getting the NFS Stale Handle.
My guess is that the problem derives from an earlier snapshot and it carried on. I had isolated the problem before by renaming that specific folder and copying a working version. It is the following folder "/usr/share/zoneinfo.old/posix/America" that contains the corrupted files. I cannot even stat them.

(in between) today I committed slightly modified btrfs-autosnapshot (xbian-package-config-shell package) with those syncs and a bit more checking for failed commands during the script. I cloned (with autosize - so just xbian-config from ssh and specified dest part) 5GB installation to USB stick with no issues.
(this doesn't automatically assume I'm right user wrong - just currently I run out of possibilities what can be reason for you to fail. ok for you maybe this historical discrepancies, but I have just read from Iridium that on Cubox-i it is not working at all).
Of course try after you clear the problems on fs and report back. BTW: before you try, please DOUBLE CHECK if the destination partition is mounted or not. Should not be. The script is trying to umount it if mounted, but if it is being accessed script can continue without being able to format/mount it and (unfortunately) it is btrfs so any operation like multimounts etc is working so result != 0 is not there

for you: be sure you have btrfs-tools higher than 3.14xbian and updated initramfs. if you have keyboard reboot into it, if you don't, modify cmdline.txt as follows:


as you reboot your initramfs shell will be available via telnet. from telnet run btrfs check /dev/XXX (you can first wthout --repair - dry-run)

((when you telnet into it, take over console "busybox conspy -f". after you are done just do exit and boot will continue - but the exit needs to be put from console (you took over))).