Hi, Amit Uttamchandani wrote: > On Fri, Aug 30, 2013 at 08:39:13AM +0200, Jean-Pierre André wrote: > > [snip] > > >>> Hi, >>> >>> Thanks for the heads up. I have been testing the fallocate and found >>> that the "Initialized size" is 0: >>> >>> $ sudo ntfsinfo -F test /dev/sdf1 >>> ... >>> Dumping attribute $DATA (0x80) from mft record 64 (0x40) >>> Resident: No >>> Attribute flags: 0x0000 >>> Attribute instance: 2 (0x2) >>> Compression unit: 0 (0x0) >>> Data size: 4294967296 (0x100000000) >>> Allocated size: 4294967296 (0x100000000) >>> Initialized size: 0 (0x0) >>> End of inode reached >>> >>> Thus, when I try to write to it using the ntfs kernel driver. I get the >>> following: >>> >>> [ 661.132777] NTFS-fs error (device sdf1): ntfs_write_block(): Writing >>> beyond initialized size is not supported yet. Sorry. >>> >>> Is this the expected behavior? >>> >> I have no much knownledge of the kernel ntfs driver, >> but I far as I remember, it can only overwrite existing >> data. You appear to have preallocated 4GB of data and >> created a 4GB file. However the preallocated zone has >> not been written to, and the data beyond initialized >> size appear as zeroed. This is a valid condition, but >> you hit an unimplemented condition. >> >> As the space is actually preallocated, and, provided >> you leave no hole between initialized size and the >> zone to be written, you might try to skip the failing >> test, and update initialized size to the end of the >> successfully written part. As the runlist need not be >> updated, this could work. (never tried myself, just >> a suggestion). If it does, replace the test by one that >> checks the attribute is not sparse and you are not >> writing beyond allocated size, and if writing beyond >> data size, set data size to the end of written part. >> >> > Thanks for the reply. > > I made a simple change, I set the initialized size to be equal to data > size: > > attr->initialized_size = cpu_to_le64(na->data_size); > > instead of: > > attr->initialized_size = cpu_to_le64(na->initialized_size); > > That seems to have solved the issue I was having. Now, I am using the > fuse drive to do the writes and all works as expected. > > What do you think of that change? >
This is wrong, you make the file to be visible up to its apparent size, even in parts not yet written to. However this shows that what I suggested (quoted above) would do the job. Initialized size serves as a fence to indicate the part of a file which has not been written to, and should not be disclosed. This allocated space may contain data left over by another user. Data size is the apparent size of the file and the space between initialized size and data size must appear as zeroed when read. A bad limitation of ntfs is that when you write near the end of file, you have to zero the gap from the previous initialized space, and that may take a long time, but this is not a problem if you write sequentially from the beginning. Note : I have implemented a full ntfsfallocate, but my tests show that Windows sometimes crashes when writing to preallocated space, so I will not release such code. Regards Jean-Pierre ------------------------------------------------------------------------------ Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk _______________________________________________ ntfs-3g-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
