Package: git-annex
Version: 3.20121211
Severity: normal
Hi,
I am trying to use git-annex with a transfer repo on a USB drive. I'm using
VFAT so I'm using a bare repo. (I did try using ext4 on my USB drive but that
was painful because of the differing UIDs on different machines). The drive is
mounted with:
/dev/sdb1 on /media/IanCampbell type vfat
(rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0077,codepage=cp437,iocharset=utf8,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks)
Pushing content to the USB drive (git annex copy --to=usbdrive --auto) is
failing with lots and lots (I don't know if it started at the very begining,
but once it had started it kept on for every file AFAICT):
<<<---begin--->>>
copy Saxon - Wheels Of Steel/10-Judgement Day (Live).ogg (to usbdrive...)
SHA256E-s4762020--5ae1fc4c3220618153f4f3910cfa1b49b97a31e5c570e0dc7f322ff114322f71.ogg
4762020 100% 68.34MB/s 0:00:00 (xfer#1, to-check=0/1)
sent 4762750 bytes received 31 bytes 9525562.00 bytes/sec
total size is 4762020 speedup is 1.00
mv: cannot move
`/media/IanCampbell/music.annex/annex/tmp/b70_ab2_SHA256E-s4762020--5ae1fc4c3220618153f4f3910cfa1b49b97a31e5c570e0dc7f322ff114322f71.ogg.log'
to
`/media/IanCampbell/music.annex/annex/journal/b70_ab2_SHA256E-s4762020--5ae1fc4c3220618153f4f3910cfa1b49b97a31e5c570e0dc7f322ff114322f71.ogg.log.tmp22466':
No space left on device
failed
<<<---end--->>>
If a strace the mv then it ends with:
<<<---begin--->>>
write(1, "`/media/IanCampbell/music.annex/"...,
300`/media/IanCampbell/music.annex/annex/tmp/b70_ab2_SHA256E-s4762020--5ae1fc4c3220618153f4f3910cfa1b49b97a31e5c570e0dc7f322ff114322f71.ogg.log'
->
`/media/IanCampbell/music.annex/annex/journal/b70_ab2_SHA256E-s4762020--5ae1fc4c3220618153f4f3910cfa1b49b97a31e5c570e0dc7f322ff114322f71.ogg.log.tmp22466'
) = 300
rename("/media/IanCampbell/music.annex/annex/tmp/b70_ab2_SHA256E-s4762020--5ae1fc4c3220618153f4f3910cfa1b49b97a31e5c570e0dc7f322ff114322f71.ogg.log",
"/media/IanCampbell/music.annex/annex/journal/b70_ab2_SHA256E-s4762020--5ae1fc4c3220618153f4f3910cfa1b49b97a31e5c570e0dc7f322ff114322f71.ogg.log.tmp22466")
= -1 ENOSPC (No space left on device)
write(2, "mv: ", 4mv: ) = 4
write(2, "cannot move `/media/IanCampbell/"..., 311cannot move
`/media/IanCampbell/music.annex/annex/tmp/b70_ab2_SHA256E-s4762020--5ae1fc4c3220618153f4f3910cfa1b49b97a31e5c570e0dc7f322ff114322f71.ogg.log'
to
`/media/IanCampbell/music.annex/annex/journal/b70_ab2_SHA256E-s4762020--5ae1fc4c3220618153f4f3910cfa1b49b97a31e5c570e0dc7f322ff114322f71.ogg.log.tmp22466')
= 311
write(2, ": No space left on device", 25: No space left on device) = 25
write(2, "\n", 1
) = 1
lseek(0, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
close(0) = 0
close(1) = 0
munmap(0x7ff323f24000, 4096) = 0
close(2) = 0
exit_group(1) = ?
<<<---end--->>>
The VFAT mount point is /media/IanCampbell which means that the remainder of
the path is 120 bytes for the source and 133 bytes for the destination.
Wikipedia tells me that the maximum filename length is 256 UTF-16 characters,
it doesn't seem to say anything about the maximum path length but I wonder if
it might be the same?
To counter to that hypothesis I was able to manually create a file
music.TESTX/annex/journal/b70_ab2_SHA256E-s4762020--5ae1fc4c3220618153f4f3910cfa1b49b97a31e5c570e0dc7f322ff114322f71.ogg.log.tmp22466
which has the same length as the problematic file so perhaps this is not a path
name limitaition but something else?
annex/journal has 7281 files in it, which is less than the number of objects
I'd expect (this repo has >14,000 files in it), but doesn't seem like a likely
FS limit (wikipedia doesn't say anything about files-per-directory limits).
Is the fact that after this error it continued a problem or is that deliberate?
Will this inability to update the journal have corrupted the annex at all?
There does seem to be roughtly the amount of data present that I would expect.
It did eventually finish with:
git-annex: copy: 6962 failed
so I guess it did notice at least (and 7281+6962=14143, which is about the
right number). But "git annex whereis" tells me that at least some files are
not on the USB drive, while others are:
<<<---start--->>>
$ git annex whereis AC\\DC\ -\ Back\ In\ Black/01-Hells\ Bells.ogg
whereis AC\DC - Back In Black/01-Hells Bells.ogg (2 copies)
b3b69bb2-49b0-11e2-8cd9-936aa6733fdb -- usbdrive (Portable USB Drive)
d5348a00-4894-11e2-85d4-938793287612 -- here (Music on dagon)
ok
$ git annex whereis Saxon\ -\ Wheels\ Of\ Steel/10-Judgement\ Day\ \(Live\).ogg
whereis Saxon - Wheels Of Steel/10-Judgement Day (Live).ogg (1 copy)
d5348a00-4894-11e2-85d4-938793287612 -- here (Music on dagon)
ok
<<<---end--->>>
One thought I have is to use a backend with a shorter checksum component. I
suppose I should try the SHA1 backend (this is just my music collection, so
security isn't a huge concern).
Thanks,
Ian
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'),
(500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages git-annex depends on:
ii curl 7.26.0-1
ii git 1:1.7.10.4-1+wheezy1
ii libc6 2.13-37
ii libffi5 3.0.10-3
ii libgmp10 2:5.0.5+dfsg-2
ii libgnutls26 2.12.20-2
ii libgsasl7 1.8.0-2
ii libidn11 1.25-2
ii libpcre3 1:8.30-5
ii libxml2 2.8.0+dfsg1-7
ii libyaml-0-2 0.1.4-2
ii openssh-client 1:6.0p1-3
ii rsync 3.0.9-4
ii uuid 1.6.2-1.3
ii wget 1.13.4-3
ii zlib1g 1:1.2.7.dfsg-13
Versions of packages git-annex recommends:
ii bind9-host 1:9.8.1.dfsg.P1-4.4
ii gnupg 1.4.12-6
ii lsof 4.86+dfsg-1
Versions of packages git-annex suggests:
pn bup <none>
pn graphviz <none>
ii libnss-mdns 0.10-3.2
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
