Exception raised during create

[imrosca]

Running Arch Linux on a Raspberry Pi I installed attic 0.15 from a community repo in the AUR and I mounted two drives, /mnt/diskstation/backup is a cifs mount and /mnt/terry is USB hard drive (ntfs I think). The same exception occurred on the original attic create for Pictures-initial archive and now it occurs on every subsequent create.

$ attic create /mnt/diskstation/backup/piserv-general.attic::Video-initial /mnt/terry/Video/        
Initializing cache...
Analyzing archive: Data-initial-retry-1
Analyzing archive: Data-initial
Analyzing archive: Pictures-initial.checkpoint
hashindex: /home/robin/.cache/attic/9e58006657cfa5dacd6deaa1d50fbd0904cdd3ac06bd5efb26600534b3b06a2c/chunks: fwrite failed
Traceback (most recent call last):
  File "/usr/bin/attic", line 3, in <module>
    main()
  File "/usr/lib/python3.4/site-packages/attic/archiver.py", line 728, in main
    exit_code = archiver.run(sys.argv[1:])
  File "/usr/lib/python3.4/site-packages/attic/archiver.py", line 718, in run
    return args.func(args)
  File "/usr/lib/python3.4/site-packages/attic/archiver.pe-packagy", line 101, in do_create
    cache = Cache(repository, key, manifest)
  File "/usr/lib/python3.4/site-packages/attic/cache.py", line 61, in __init__
    self.commit()
  File "/usr/lib/python3.4/site-packages/attic/cache.py", line 162, in commit
    self.chunks.write(os.path.join(self.path, 'chunks').encode('utf-8'))
  File "attic/hashindex.pyx", line 51, in attic.hashindex.IndexBase.write (attic/hashindex.c:1256)
Exception: hashindex_write failed

[jborg]

You're most likely running out of disk space on the /home/robin/.cache filesystem

[imrosca]

Thanks. That was it. Makes sense now.
On 28/04/2015 5:53 am, "Jonas Borgström" notifications@github.com wrote:

You're most likely running out of disk space on the /home/robin/.cache
filesystem

—
Reply to this email directly or view it on GitHub
#298 (comment).

[ThomasWaldmann]

close please.

[unode]

Hi guys,

I'm seeing a similar problem with attic 0.16 but space doesn't seem to be the problem. More like it doesn't even try to create the file on the listed location.

This happened after a few hours transferring quite a lot of data 100GB+.

Subsequent calls fail with this error in under 30 seconds.

I'm using a passphrase.

The traceback I get is:

Initializing cache...
Analyzing archive: hostname-2016-02-10.checkpoint
hashindex: /home/u/.cache/attic/ade7679ec0bc235da664a8274cedca4406a8e0c1ae275cc88ffb78cc00d46d3e/chunks: fwrite failed
Traceback (most recent call last):
  File "/home/u/system/anaconda3/envs/attic/bin/attic", line 4, in <module>
    __import__('pkg_resources').run_script('Attic==0.16', 'attic')
  File "/home/u/system/anaconda3/envs/attic/lib/python3.5/site-packages/setuptools-19.6.2-py3.5.egg/pkg_resources/__init__.py", line 724, in run_script
  File "/home/u/system/anaconda3/envs/attic/lib/python3.5/site-packages/setuptools-19.6.2-py3.5.egg/pkg_resources/__init__.py", line 1649, in run_script
  File "/home/u/system/anaconda3/envs/attic/lib/python3.5/site-packages/Attic-0.16-py3.5-linux-x86_64.egg-info/scripts/attic", line 3, in <module>
    main()
  File "/home/u/system/anaconda3/envs/attic/lib/python3.5/site-packages/attic/archiver.py", line 730, in main
    exit_code = archiver.run(sys.argv[1:])
  File "/home/u/system/anaconda3/envs/attic/lib/python3.5/site-packages/attic/archiver.py", line 720, in run
    return args.func(args)
  File "/home/u/system/anaconda3/envs/attic/lib/python3.5/site-packages/attic/archiver.py", line 101, in do_create
    cache = Cache(repository, key, manifest)
  File "/home/u/system/anaconda3/envs/attic/lib/python3.5/site-packages/attic/cache.py", line 61, in __init__
    self.commit()
  File "/home/u/system/anaconda3/envs/attic/lib/python3.5/site-packages/attic/cache.py", line 164, in commit
    self.chunks.write(os.path.join(self.path, 'chunks').encode('utf-8'))
  File "attic/hashindex.pyx", line 51, in attic.hashindex.IndexBase.write (attic/hashindex.c:1304)
Exception: hashindex_write failed

Any ideas how I can debug this further?

[ThomasWaldmann]

Is it that? #298 (comment)

[unode]

@ThomasWaldmann as mentioned, no space doesn't seem to be the problem.
~/.cache has plenty of space as does the repository location. I just created a 10GB file there to confirm and no errors.

[ThomasWaldmann]

Hmm, that's strange. Just guessing: check the filesystem and the underlying disk?

[unode]

I'm running attic check on the repository as we speak. It will take a while...

I can't really check the filesystem (no root access nor can I reboot), but I don't see anything else failing. The cache is on a local disk, the repository is located on an NFS share. Even if a glitch happened at some point in time during the initial backup, subsequent backups should be able to recover from it, no?

[ThomasWaldmann]

As the cache file is local (see path in line 3 of the output you posted), I meant a fsck of that filesystem and e.g. smartctl -t long of that disk.

[unode]

Hum... I thought .cache was on the remote side...
False alarm then, it is the same problem as comment #298.
The folder was growing beyond 600MB.