Re: umount waiting for 12 hours and still running

[John Goerzen <jgoerzen@complete.org>]

Duncan <1i5t5.duncan <at> cox.net> writes:

> 
> John Goerzen posted on Tue, 05 Nov 2013 07:42:02 -0600 as excerpted:
> 
> > The filesystem in question involves two 2TB USB hard drives.  It is 49%
> > full.  Data is RAID0, metadata is RAID1.  The files stored on it are for
> > BackupPC, meaning there are many, many directories and hardlinks.  I
> > would estimate 30 million inodes in use and many of them have dozens of
> > hardlinks to them.
> 
> That's a bit of a problem for btrfs at this point, as you rightly mention.

Hi Duncan,

Thank you very much for taking the time to reply.

Can you clarify a bit about what sort of problems I might expect to
encounter with this sort of setup on btrfs?

> 
> > I thought perhaps converting metadata to raid0 would help.  So I
> > started a btrfs balance start -mconver=raid0 on it.
> 
> > Kernel 3.10 from Debian wheezy backports on i386.
> 
> There's a known bug with balance on current kernels related to pre-
> allocated space (as with the systemd journal or torrent files with some 
> clients).

[snip ]

> http://permalink.gmane.org/gmane.comp.file-systems.btrfs/287

I'm almost completely sure that this bug wasn't being hit.  The files were
streamed back by restore(8), and a few written by BackupPC.  I checked the
source to both just to make sure, and neither have a call to fallocate.  I
do not believe there were sparse files on the disk either.   I also haven't
experienced the csum errors mentioned in the post.   

Thanks again,

-- John