From: Moreno B. <ba...@de...> - 2004-03-28 22:02:58
|
Hi devel-oMers, here's a simple demo which shows the effect of the oMFS bug(?) that mess up coreutils-cp. stat() and fstat() syscalls, on the same file, should set an identycal 'stat' structure (the former needs a filename, the latter a file descriptor). This is not true when these calls get the info for any mfs file: the st_dev field looks different. Try to run this code against any file (or dir) on local filesystem and then try it against any mfs file. For instance: ./mfs_stat_bug / ./mfs_stat_bug /net/mfs/here Take a look at st_dev on the latter example. First 4 bytes seem ok, should be 8 but look like st_dev, then... mmh, looks like the node number... %-> Two examples, st_dev printed as dev_t (uint64_t, unsigned long long): /mfs/2: 0x08050002000000ff /mfs/21: 0x08050015000000ff I can suppose that: - first 4 bytes (int32_t!) is st_dev: 0x000000ff - 2 bytes as node number (int16_t?) node 2 = 0x0002 node 21 = 0x0015 (this weird theory works for other nodes-number too) but what are the last 4 bytes: 0x0805? (0x0100, 0x0302 on other oM clusters) Anyway, suppositions aside, is it a problem of boundaries? Moshe, Vincent, any mfs hacker all over the world, is there a bug? Am I paranoid? :) Ciao Moreno |