Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
/ 2004-04-01 16:37:55 +0900 \ "Kotrappa(?????)": > Is it possible ? to use just dd command bypassing file systems?? > i.e dd if=/dev/mem of=/dev/nb1 bs=1024 count=10 Many things are possible. Not all of them make sense. This definitely does not. sure, it is possible to do this: $ROOT_DEV = `mount | grep "on \/ " | cut -d " " -f 1` dd if=/dev/zero of=$ROOT_DEV bs=4k But you won't actually try it, would you? > I use SUDF ( secure universal disk format filesystem) if that works. won't work anyways, unless someone has a cluster aware derivative of it. To clarify: You want to have more than one node concurrently writing to the same file system, which in turn is even submitted to more than one physical storage. The file system and block device and whatnot drivers need to make sure that strict write ordering is guranteed, and that proper locking guarantees that the "concurrency" in IO requests is serialized in the right way. This is complexity on each level from the file system driver almost down to the hardware driver. The full stack of drivers need to guarantee write ordering [1], and at least the topmost (i.e. the file system driver) needs to guarantee proper exclusion [2] of concurring IO requests, on all nodes. Currently DRBD could (with minor tweaks at the *right* places; no, I won't explain it here, because of [3]) do [1], you still need some fs like (Open)GFS to do [2]. I did not even mention what might happen if the communication between the nodes, or one of the physical storage devices, or even one of the nodes, fails. [3] The complexity resulting from these failure an recovery scenarios is the reason why DRBD does not support this (yet). If you have a well thought concept about how each failure scenario and recovery from it should be handled, covering which node may still access a device in which failure cases, how should be determined which node has the valid data after some failure, how should resynchronization be done and so on and on and on ... IFF you have such a concept, and a well founded understanding of it, tell us about it. We shall be very thankful. Otherwise, just stop blindly trying things which won't work. Lars Ellenberg