Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
> On Fri, Jun 22, 2007 at 11:32:51AM -0500, CA Lists wrote: >> There was nothing on the drives at all. In a chicken-before-egg type of >> situation, since I don't have /dev/sdb mounted anywhere on the iSCSI >> targets, I thought I would need to get OCFS2 up and running on one of the >> nodes and format the drive to be able to do anything with it. Then, I found >> out ocfs2 provides no way to shrink a filesystem. > > the correct way to set up a fresh file system on drbd is to > * setup drbd, > * then do mkfs /dev/drbdX, > and all will be fine. > >> So, /proc/partitions shows a number that is 29492 smaller, which means bad >> things, right? In other words, I need to probably re-make the ocfs2 file >> system to be smaller, correct? > > if you just make it on top of drbd, all is fine. OK, so on the target machine, I just remade the file system with mkfs.ocfs2 and now my number from /proc/partitions is larger by 12 blocks, which means my data will now be safe, right? > > > what are you trying to do there? > > I mean, if I would export some blockdevice via iSCSI, > I'd not mount it locally, even with a cluster fs. > it just does not feel right, and probably asks for trouble > like resoiurce starvation deadlocks. That's what got me confused to begin with. I wanted to avoid mounting it locally. My issue was how to format a drive for ocfs2 without one of the nodes being able to see it. I was being stupid though - just had to export the /dev/drbd0 device over iSCSI, then format the device. > (well, actually, all block-io via linux network stack asks for trouble > of this kind, though it has been getting better.) >