Immidiate update of filesystem?

Software-based VM-centric and flash-friendly VM storage + free version

Moderators: anton (staff), art (staff), Max (staff), Anatoly (staff)

Guest

Wed Jul 21, 2004 1:36 am

i have a workstation and a server - both winxp - both ntfs.
i share the 2 hds of the server via starwind.
when i write a file onto the share drive i can't see or access it from the servers logged-in account. even the free disk space is not updated. if i write a file from the server's logged-in account i can't access or see it from the workstation (where starport is running).

why's that?

greetings
cosinus
guest

Wed Jul 21, 2004 8:41 am

maybe some more details:

machine a)
server,
winxp pro, 2x hd (ntfs), (both shared with starwind)
user x logged on local account.

machine b)
workstation,
winxp pro 3 x hd (ntfs), 2x cd/dvd-rw + 2 x (shared from machine a)) hd

if i sit at machine b) and write a file to the shared hd from machine a) and then go at the other room to machine a) and take a look at the hd - i don't see that file. is that a winxp multi-user-limitation. isn't ntfs made for that. i know that changes on a linux box with different users logged on and writing files changes are made immidiately.

cosinus
User avatar
Alex (staff)
Staff
Posts: 177
Joined: Sat Jun 26, 2004 8:49 am

Wed Jul 21, 2004 10:36 am

Hi,
Guest wrote:i have a workstation and a server - both winxp - both ntfs.
i share the 2 hds of the server via starwind.
when i write a file onto the share drive i can't see or access it from the servers logged-in account. even the free disk space is not updated. if i write a file from the server's logged-in account i can't access or see it from the workstation (where starport is running).

why's that?

greetings
cosinus
I guess you share your drives as:

add \\.\PhysicaldriveX -share:rw

The thing is that the configuration when several clients (StarPort and the server's OS in you example) access the same drive is not supposed to work correctly with read/write devices. Because file system's data is not synchronized between clients. If you will try to use such a configuration you will get corrupted file system.

So you should use exclusive access configuration only:

add \\.\PhysicaldriveX -share:""

PS. Two requirements should be satisfied in order to use shared configuration:

1. Distributed/cluster file system should be used. NTFS is not an option.
2. Support of RESERVE/RELEASE commands should be supported by iSCSI target.

Implementation of the 2nd requirement in StarWind is considered now.
Best regards,
Alexey.
Guest

Thu Jul 22, 2004 1:02 am

Code: Select all

 If you will try to use such a configuration you will get corrupted file system.
*g* got a corrupted filesystem. took me 2 hours to repair. lucky me. i see ntfs is not an option ... :(

greetings
cosinus
User avatar
anton (staff)
Site Admin
Posts: 4008
Joined: Fri Jun 18, 2004 12:03 am
Location: British Virgin Islands
Contact:

Thu Jul 22, 2004 2:05 am

Really sorry for this! But you was warned. Currenlty we're looking for distributed file system vendor to coopeate with. But no luck so far...

Sorry again. Do you think we should *BLOCK* this "feature"?
Guest wrote:

Code: Select all

 If you will try to use such a configuration you will get corrupted file system.
*g* got a corrupted filesystem. took me 2 hours to repair. lucky me. i see ntfs is not an option ... :(

greetings
cosinus
Regards,
Anton Kolomyeytsev

Chief Technology Officer & Chief Architect, StarWind Software

Image
Guest

Fri Oct 22, 2004 11:10 am

i do think u should block it for the time being. Might save people a lot of trouble (like me :)) . Or at least mention it somewhere.
User avatar
anton (staff)
Site Admin
Posts: 4008
Joined: Fri Jun 18, 2004 12:03 am
Location: British Virgin Islands
Contact:

Fri Oct 22, 2004 12:14 pm

We'll do both! New version 2.4.2 (already available from download section) has SPTI access blocking local file system calls.

You'll still be capable to crash your disk FS structures with concurrent iSCSI access but this is switchable with "Cluster support enabled" option. So we assume you know what you're doing.

And we'll update the docummentation of course!

Thank you for feedback and sorry once again :-(
Anonymous wrote:i do think u should block it for the time being. Might save people a lot of trouble (like me :)) . Or at least mention it somewhere.
Regards,
Anton Kolomyeytsev

Chief Technology Officer & Chief Architect, StarWind Software

Image
si.

Sat Oct 23, 2004 6:01 pm

ok, ok. now you got me all heated up. :D

What do you mean by 'cluster support'. And how do I enable/disable it to keep my FS safe (I am using the latest version)?

What I want to do is something like a SMB (windows) share but over iSCSI. I would like to have at least 10 systems (only windows for now :wink: ) accessing the fileserver over iSCSI. That is obviosuly no problem by itself until I tell you that they need to access the same data (R/W). We had a windows share for now but that's obviously a very slow option :( . So can I do this or not with StarWind? Can you post a config line(s) (using partition F: )?

If I can, is it important what initiator I use? We would probablly use StarPort but if someone uses the MS initiator, I don't want my FS corrupt.

Can we access the shared partition locally or do we need to always use it over iSCSI (mainly for backup).

Hope I didn't ask too many questions, but I am sure a lot of other visitiors are asking themselves the same questions...

si.
User avatar
anton (staff)
Site Admin
Posts: 4008
Joined: Fri Jun 18, 2004 12:03 am
Location: British Virgin Islands
Contact:

Sat Oct 23, 2004 11:05 pm

Under cluster support I mean exactly cluster support :-) StarWind can be configured to run Microsoft cluser services over emulated hard disk. I guess any other cluser software taking care of RESERVE/RELEASE SCSI commands would work also. However in MS particular case there's no way to provide concurrent access to the same hard disk at the logical block level. You'll have only failover. So when one node of the cluser would fail second (or third, or ... node) would grab shared disk and continue running just as nothing happened.

However to share the volume you'll need something more advanced then NTFS to be present on the top of the storage stack. We have successfully tested and confirmed working DataFlow SFS (SAN File System) from www.dataplow.com. You can write them down and ask for demo version of their file system for Windows 2000/XP and up.
si. wrote:ok, ok. now you got me all heated up. :D

What do you mean by 'cluster support'. And how do I enable/disable it to keep my FS safe (I am using the latest version)?

What I want to do is something like a SMB (windows) share but over iSCSI. I would like to have at least 10 systems (only windows for now :wink: ) accessing the fileserver over iSCSI. That is obviosuly no problem by itself until I tell you that they need to access the same data (R/W). We had a windows share for now but that's obviously a very slow option :( . So can I do this or not with StarWind? Can you post a config line(s) (using partition F: )?

If I can, is it important what initiator I use? We would probablly use StarPort but if someone uses the MS initiator, I don't want my FS corrupt.

Can we access the shared partition locally or do we need to always use it over iSCSI (mainly for backup).

Hope I didn't ask too many questions, but I am sure a lot of other visitiors are asking themselves the same questions...

si.
Regards,
Anton Kolomyeytsev

Chief Technology Officer & Chief Architect, StarWind Software

Image
Joco
Posts: 3
Joined: Tue Nov 09, 2004 6:12 pm

Tue Nov 09, 2004 6:20 pm

Hi Anton,

I have contacted the DataPlow and after quite a long procedure I hve recieved the software. The plan was to setup a system like this:
1. one workstation, named X, with an empty disk with StarWind iSCSI target and running SFS as server,
2. one workstation, named A, with the iSCSI target attached and running SFS as client,
3. one workstation, named B, with the iSCSI target attached and running SFS as client.

Unfortunately when adding a target like
add \\.\PhysicalDrive1 -share:"rw" -sessions:10

local mount of the target does not work. I have tried it with MS and StarPort initiator without success. The drive is mounted but useless.

The only indication of what might be the problem is an Event log entry of:
Disk 2 will not be used because it is a redundant path for disk 1.

This (to me) indicates that Windows recognize the new drive as being the same as the physical one.

For this reason I was forced to use machine A as the SFS server which reduces performance to useless.

I can send you the logs if you like.

Joco
Joco
Posts: 3
Joined: Tue Nov 09, 2004 6:12 pm

Tue Nov 09, 2004 6:22 pm

Hi Anton,

I have contacted the DataPlow and after quite a long procedure I hve recieved the software. The plan was to setup a system like this:
1. one workstation, named X, with an empty disk with StarWind iSCSI target and running SFS as server over iSCSI,
2. one workstation, named A, with the iSCSI target attached and running SFS as client,
3. one workstation, named B, with the iSCSI target attached and running SFS as client.

Unfortunately when adding a target like
add \\.\PhysicalDrive1 -share:"rw" -sessions:10

local mount of the target does not work. I have tried it with MS and StarPort initiator without success. The drive is mounted but useless.

The only indication of what might be the problem is an Event log entry of:
Disk 2 will not be used because it is a redundant path for disk 1.

This (to me) indicates that Windows recognize the new drive as being the same as the physical one.

For this reason I was forced to use machine A as the SFS server which reduces performance to useless. Another problem is that StarWind in the free version obviously only supports two client connections, but that is acceptable for now (although 1 more would really help the evaluation).

I can send you the logs if you like.

Joco
Val (staff)
Posts: 496
Joined: Tue Jun 29, 2004 8:38 pm

Tue Nov 09, 2004 10:51 pm

Hi Joco,

The problem with your SPTI mapped drive is it seems not to support RESERVE/RELEASE SCSI ops itself. So it can't be used in MS clustering environment or SFS filesystem for reliable access by multiple initiators.

Using the ImageFile plugin is the way to go (at least for now).

To share your storage space with the ImageFile you should create a partition on the hard drive and format it to a usual FS (NTFS is a good choice).
Then you create an image file with mksparse.exe which is included into StarWind installation. And share the image file as a virtual hard drive.

Please read the following topic for more details:
http://www.starwindsoftware.com/forums/ ... c.php?t=84
Best regards,
Valeriy
Joco
Posts: 3
Joined: Tue Nov 09, 2004 6:12 pm

Wed Nov 10, 2004 10:40 am

Are you sure images can be RW shared? Log states only one connection is allowed.

I have done as you suggested. I formatted my E: drive with NTFS. Drive size iz 40 GB.

I have then used mksparse to create a 10GB image named image.img. My conf lines:

addplugin -module:"ImageFile.dll" -symlink:"ImageFile" -type:"Image file" -imagedir:"e:\" -imagemask:"*.img"

add "ImageFile0" -file:"image.img" -asyncmode:"no" -share:"rw" -sessions:10

And here is the log:
ImageFile[6b4] *SscPort_Create: Opening device 'ImageFile0', image file 'image.img'.
ImageFile[6b4] ImageFile_Create: Disk structure allocated OK
ImageFile[6b4] *ImageFile_Create: 'e:\\image.img': Disk geometry: Sect/Track= 16, Tracks/Cyl= 32, Ncyl= 40960, TotalSectors: 20971520
ImageFile[6b4]->ImageFile_BuildInquiry >>
ImageFile[6b4] *ImageFile_BuildInquiry: Use default VendorId
ImageFile[6b4] *ImageFile_BuildInquiry: Use default ProductId
ImageFile[6b4] *ImageFile_BuildInquiry:
VendorId = 'ROCKET '
ProductId = 'IMG DISK 10 GB '
Revision = '0001'
ImageFile[6b4]<-ImageFile_BuildInquiry << Return (0x0)
ImageFile[6b4] ImageFile_Create: Disk creation succeded.
10:28:21:843 (0x6b4) func: <<< iScsiSscDevice::open
10:28:21:843 (0x6b4) S: the device 'ImageFile0' is opened successfully.
10:28:21:843 (0x6b4) S: Assigned target name: 'iqn.2003-06.com.rocketdivision.starwind:xp-jozem.ixtlan-team.si.imagefile.imagefile0', SymId: 'Imagefile.ImageFile0'.
10:28:21:843 (0x6b4) S: parameter 'header', value '0'.
10:28:21:843 (0x6b4) S: parameter 'file', value 'image.img'.
10:28:21:843 (0x6b4) S: parameter 'buffering', value 'no'.
10:28:21:843 (0x6b4) S: clustered 0.
10:28:21:843 (0x6b4) S: parameter 'asyncmode', value 'no'.
10:28:21:843 (0x6b4) S: iqn.2003-06.com.rocketdivision.starwind:xp-jozem.ixtlan-team.si.imagefile.imagefile0: 1 session(s) allowed.
10:28:21:843 (0x6b4) conf: Target [0x841c0] has been created. Device 'ImageFile0' is accesible as target 'iqn.2003-06.com.rocketdivision.starwind:xp-jozem.ixtlan-team.si.imagefile.imagefile0'.
10:28:21:843 (0x6b4) func: >>> iScsiServer::refreshDeviceList
Val (staff)
Posts: 496
Joined: Tue Jun 29, 2004 8:38 pm

Wed Nov 10, 2004 10:59 am

Joco,

To allow multiple access to an image file you need add "-clustered:yes" to the 'add' rule.
This will allow up to 256 iSCSI initiators to access the target simultaneously.

Please change your config file settings like this:

add "ImageFile0" -file:"image.img" -asyncmode:"no" -clustered:"yes"

BTW, setting '-asyncmode:yes' can speed up the disk operations if the image file is stored on a RAID volume...
Best regards,
Valeriy
tintin04
Posts: 3
Joined: Wed Nov 08, 2006 9:58 am

Wed Nov 08, 2006 10:08 am

Hello,
With Starwind v3.1.4 (Build 20060716, Win32) can I resolve this problem (2 computer can see others updates in RW mode)

Or if Starwind not support this, is there any solution to solve this (like using SAN)?

Thanks
Duc
Post Reply