Problem with disklabel and filesystem over iSCSI

[Erik Scholtz, ArgonSoft GmbH]

ok, i started the system in single-user-mode and brought up the iSCSI 
connection. I tried to install the ufs first, after each step I synced. 
  No change - problem remains the same (newfs is failing).

Then I installed the ZFS again, also synced after each step, then 
unmounted the iSCSI device, synced again (always at least three times). 
Then rebooted the system (going to single-user-mode again) and the ZFS 
is corrupted again with the same message.

I don't think the buffers are the problem.

Erik

-----
ArgonSoft GmbH      | Im Ermlisgrund 3      | 76337 Waldbronn
Tel: +49 7243 71520 | Fax: +49 7243 715222  | http://www.argonsoft.de
Umsatzsteuer-Identnummer: DE205762306       | Handelsregister: HRB2372E
Geschäftsführer: Erik Scholtz

Danny Braniss wrote:
 >
 > ok, so the problem is on shutdown/reboot. Buffers don't seem to be
 > flushed.
 > To check if this is correct, try shutdown, then under single user
 > unmount the iscsi, sync, sync, reboot
 >
 > danny
 >
>> Hi,
>>
>> I tested the default iSCSI_initiator shipped with 7.0, 7.1RC1 and 
>> 7.1RC2. Additionally i changed it with that version from 
>> ftp://ftp.cs.huji.ac.il/users/danny/freebsd/iscsi-2.1.tar.gz with each 
>> release. The effect is with all combinations the same:
>>
>> 7.0 native / 7.0 + iscsi-2.1
>> 7.1RC1 native / 7.1RC1 + iscsi-2.1
>> 7.2RC2 native / 7.2RC2 + iscsi-2.1
>>
>>
>> Additionally info + tests:
>> --------------------------
>> 1) I also checked it for ufs in dangerously dedicated mode - also the 
>> same effect.
>>
>> 2) After the reboot, the iSCSI device is back on /dev/da0 as expected.
>>
>> 3) The SAN system is a Hardware-SAN (iStor / GigaStor), that works 
>> without any problems under Ubuntu, CenOS, MacOS X, Windows and RedHat 
>> (all tested the last days)
>>
>> 4) I could get ufs to work with the following (terribly wrong) partition 
>> map:
>>
>>           0         40         39        -     12     unused        0
>>          40     409600     409639    da0s1    165    FreeBSD        0
>>      409640 1928708016 1929117655    da0s2    165    FreeBSD        0
>> 1929117656     262184 1929379839        -     12     unused        0
>>
>> With this partition map, newfs runs without any failure. The filesystem 
>> is heavily damaged and can be repaired with fsck. After repairing, the 
>> fs can be mounted and used as normal. But when running a fsck, thousands 
>> of errors must be corrected and the result is an empty disk again (when 
>> answering all with YES - I ran it with -y flag, since there are too many 
>> questions to be answered manually, even when copying only three big 
>> files).