Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
This seems to be either a threading issue or a bug, or maybe something at the filesystem level... I have a DRBD cluster running over a VPN (OpenVPN), over the Internet. Each end is an Ubuntu Feisty server, with the distro's admin tools (drbdadm, etc), and a manually-compiled drbd-0.8.3 kernel module. Its purpose is backup. I was going to use ocfs2, for no reason other than coolness, but since ocfs2 likes to timeout and fence the system (by panicing the kernel), that's not an option. (If anyone here is working on ocfs2, please provide a way to fence an ocfs2 filesystem without killing the whole machine.) So, I can't remember if I had the issue on any other filesystem. Now I'm on ReiserFS, and writes are taking forever (kind of to be expected when backing up 30 gigs over a DSL line). The issue is, reads also often take forever. I never know whether a simple ls is going to be instantaneous, or take a minute or two. I have atimes off, so I am assuming that ReiserFS itself isn't turning a read into a write. I went ahead and did a simple test: root at norton:~# dd if=/dev/drbd0 of=/dev/null bs=1M count=1 1+0 records in 0+0 records out 0 bytes (0 B) copied, 245.03 seconds, 0.0 kB/s Ok, that didn't work. Trying again: root at norton:~# dd if=/dev/drbd0 of=/dev/null bs=1M count=1 1+0 records in 1+0 records out 1048576 bytes (1.0 MB) copied, 0.00658724 seconds, 159 MB/s Ok, so the first meg of the device is obviously cached. And the second meg? root at norton:~# dd if=/dev/drbd0 of=/dev/null bs=1M count=1 skip=1 1+0 records in 1+0 records out 1048576 bytes (1.0 MB) copied, 71.2569 seconds, 14.7 kB/s That's actually after I had a few others that I started, and then gave up on. One went for almost five minutes. Since I'm no longer using ocfs2, I don't have allow-two-primaries. I simply don't get why a read from the DRBD device is limited like that. Why couldn't it simply read from the local cache or the local disk, even if the writes are busy trying to send stuff to the network? Is this something that could be fixed in a future version, or is it maybe somehow a limitation of all Linux block devices? Failing any of that, does anyone know a simple filesystem which can do what drbd does (raid1 over a network), but at the FS level? If not, I'm thinking of writing one using FUSE or something... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20070530/5b0409b9/attachment.pgp>