On 23/06/10 01:32, Eric Beversluis wrote: > The discussion is getting interesting. Thanks. > > In previous rdiff backups, the .gvfs file was simply ignored. So I don't > think this could have caused the problem.
I didn't notice this one, Message from sysl...@linux-7fva at Jun 21 06:32:23 ... kernel:[121311.947209] journal commit I/O error that's some more serious problem. You should have more info saved in the syslog file. > External HDD could be the problem. I had serious trouble with a WD > Passport because of some crap on it that couldn't be removed and > basically wouldn't let me use it with Linux (and WD was very snotty > about not providing Linux support for their HDDs). Now I'm using a USB > Toshiba drive (same small size as Passport). I may need to use my > Y-cable to get appropriate and consistent power for it? While I don't know about the black magic of Y-cables, I'd take a look at the smart data of the drive, esp. Current_Pending_Sector and Reallocated_Sector_Ct . If it has more than a few bad sectors I'd try to RMA the drive. You may need additional switches for smartctl to get it to work over USB: http://sourceforge.net/apps/trac/smartmontools/wiki/Supported_USB-Devices (and it may not work at all, unfortuanately, though there are some Toshibas in the list) > > On Wed, 2010-06-23 at 00:04 +0100, Alex Pounds wrote: >> On Tue, Jun 22, 2010 at 05:43:45PM +0200, Luciano Rocha wrote: >>> On Jun 22, 2010, at 5:40 PM, Alex Pounds wrote: >>>> I hope I'm not teaching you to suck eggs, but filesystems are often >>>> remounted read-only automatically if the OS encounters errors while >>>> writing. >> >>> .gvfs is a fuse mount point. Only the user that mounted it has >>> permission to access it. Not even root does. So, while your point is >>> valid for standard filesystems, there's no need to scare for this >>> instance. :D >> >> Sure, but I don't think the .gvfs error is related to the eventual failure >> of the backup. Instead, it's a result of Eric backing up his home >> directory (which includes a .gvfs directory that has the permissions set >> as you describe). The traceback doesn't include a log of what file >> rdiff-backup was attempting to back up, but the syslog excerpt given by >> the OP includes a "journal commit I/O error" and incorrect permissions >> wouldn't result in a previously writable filesystem being remounted as >> read-only. >> > > > > _______________________________________________ > rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org > http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users > Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki _______________________________________________ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
