Good day Adrian, In regards to your "VERIFY ON" preventing disk writes to a SAN provided by gPXE's INTerrupt 13h hook:
I have seen something similar, when the device underlying my SAN is read-only. For example, I thought it might be fun to have a read-only SAN with DOS on it that multiple clients could share at the same time (I wasn't going to write any files). In Linux, I did: $ losetup -r /dev/loop0 dos.hdd $ vblade 1 1 eth0 /dev/loop0 When I SAN-booted this from gPXE, the clients did not know the the medium was read-only. They could write sectors, but those sectors could possibly be lost once 'vblade' (an AoE target program) discarded them from its buffers. Surely enough, turning "VERIFY ON" will report the fact that the sectors were not actually written. It's possible that you could achieve something similar using levels of device-mapper trickery and iSCSI. Note that the FAT filesystem (like so many other filesystems) is not intended for simultaneous use by multiple clients; that would be like having a hard drive physically attached to multiple computers with a spider-web of IDE ribbons spliced together and expecting the OS running on each computer to magically co-operate when writing to the filesystem without any awareness of the other OSs. I'm not suggesting that you're doing this. So is it possible that your SAN's underlying storage device/file is read-only? - Shao Miller _______________________________________________ gPXE mailing list [email protected] http://etherboot.org/mailman/listinfo/gpxe
