On Mon, Nov 7, 2011 at 3:34 PM, Tommi Virtanen <tommi.virta...@dreamhost.com> wrote: > On Mon, Nov 7, 2011 at 15:10, Sage Weil <s...@newdream.net> wrote: >> It applies to RBD too... _if_ the ceph-osd process is calling sync(2). >> On btrfs it doesn't, and on XFS/extN/etc., it only does on older kernels >> with older glibc. New kernels (.39+) and new glibc have syncfs(2), which >> syncs only the fs the ceph-osd is serving up. >> >> http://linux.die.net/man/2/syncfs > > I'm willing to believe syncfs(2) makes the deadlock more rare, but > isn't it still possible? > > e.g. see slide 23 of www.scs.stanford.edu/nyu/02fa/notes/l3.pdf for a > description of this in context of loopback NFS. If rbd.ko does write > caching, and uses buffer cache for it:
There are two different deadlock problems in this thread: sync deadlock (due to syncs triggering a recursive sync call) versus memory pressure writeout deadlock. The first is dealt with by using syncfs; the second is usually dealt with by using a userspace client (because then the OS can swap the userspace client memory to disk if necessary). -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
