[linux-cifs-client] CIFS Umount apparently causes loss of data

Richard Walters richard.walters at tdbnetworks.com
Mon Jun 23 11:30:02 GMT 2008


Dear linux-cifs-client list,

As root user, I am mounting a cifs mount on a RHEL4 server, where the
filstore is located on a Windows 2000 server on the same network
segment.  There are no firewalls in between the two physical machines.
CIFS version is 1.48a.RH.

I am using the following to mount the share, create a 150 Mb sparsefile,
associate the sparsefile with a loop device, create an ext3 filesystem
on the sparsefile, and then mount the subsequently created filesystem.

   mount -t cifs --verbose -o
   forcedirectio,username=<DOMAIN>\<USERNAME>,password=<PASSWORD>
   //<WINDOWS MACHINE>/<MOUNT LOCATION> /mnt/mountpoint 
    
   dd if=/dev/zero of="/mnt/mountpoint/SPARSEFILE" bs=1M count=1
   seek="150" 
    
   losetup /dev/loop20 /mnt/mountpoint/SPARSEFILE  
    
   mkfs -t ext3 /dev/loop20 
    
   mount -t ext3 /dev/loop20 /mnt/backup  
 
All of the above occurs without error. 
 
I then write files and directory structures to /mnt/backup and confirm
that they are there with all the correct permissions etc etc.  I can
manipulate the data in /mnt/backup - change permissions etc etc.
 
Then I issue: 
 
   umount /mnt/backup
   losetup -d /dev/loop20
   umount /mnt/mountpoint 
 
At this point I expect the files and directory structures written to
/mnt/backup to have been populated to the file system created in the
sparsefile, which is no longer mounted.

However, if I remount using the following: 
 
   mount -t cifs --verbose -o
   username=<DOMAIN>\<USERNAME>,password=<PASSWORD> //<WINDOWS
   MACHINE>/<MOUNT LOCATION> /mnt/mountpoint 
    
   losetup /dev/loop20 /mnt/mountpoint/SPARSEFILE  
    
   mount -t ext3 /dev/loop20 /mnt/backup  
 
I find that the data on /mnt/backup is not as I expect.  Generally,
files in the root (/mnt/backup) are as expected, but any directory
structures have disappeared.  Changed permissions on files in the root
remain changed.  Deleted files in the root partition have reappeared.
I am even getting inconsistent results on the above - depending on how
quickly I unmount, and on how many files/directories I copy to
/mnt/backup.  

It appears from investigation that the files remain until the umount of
the cifs filesystem. 

For example, if I just umount the loop device (and complete the losetup
-d), and then complete 

   losetup /dev/loop20 /mnt/mountpoint/SPARSEFILE  
    
   mount -t ext3 /dev/loop20 /mnt/backup  

Everything is just as I would expect - there are no surprises at all.
 
Initially I suspected cifs data caching, so I employed the directio
option on the cifs mount command - there has been no discernable
difference.  dmesg shows that this option is NOT rejected, but looking
at the /proc/mounts the option does not show up, although this could be
a red herring: 
 
   //WINDOWS MACHINE/MOUNT LOCATION /mnt/mountpoint cifs
   rw,mand,noatime, nodiratime,unc=\\WINDOWS MACHINE\MOUNT
   LOCATION,username=<username>,domain=<windows
   domain>,rsize=16384,wsize=57344 0 0 

It really does appear that the data loss occurs on the cifs umount - I
suspected inode caching, but the directio option should have ensured
that this was OK.

Out of interest, I have tried this on RHEL5 to a different Windows file
server, but end up with a similar result.  I have also tried using ext2
rather than ext3 filesystems - there is no change to the overall
behaviour.

I have deployed debug logging on cifs, but dmesg does not provide any
particular clue as to an underlying cause - all routine rcs = 0

Has anyone come across something similar, or can point me in the right
direction to resolve this?

Thanks and regards,

Richard
-------------- next part --------------
HTML attachment scrubbed and removed


More information about the linux-cifs-client mailing list