Hi, I'm running Samba 3.6.3 on Ubuntu 12.04 (beta). Like many before me, I'm trying to migrate data from a Windows file server. I copied over a share as a test and was a bit surprised when the amount of space allocated in the file system was over 100GB larger than the Windows source. I am running on ext4 with "strict allocate = yes" because I want to be sure that when I turn on quotas, or my users fill up the file system, that they get the same error experience which they would get under windows. Or, put another way, software expecting windows allocate-on-open semantics will get what they expect. Now, if I were copying from a Unix file system I'd expect to blame this on sparse files or hard links. However I'm under the impression that both of these are exceedingly rare under Windows. Furthermore, I would expect the Properties dialog box to show useful numbers for "Size" and "Size on disk". By "useful" I mean that if I were copying data to another disk of size X, I would expect my data to fit on that disk so long as these numbers are less than X. I'm using robocopy from the windows file server to copy the files. According to Windows there are 116,000 files and 2800 folders, and I get exactly the same values in Unix when running "find /share -type f | wc -l" and "find /share -type d | wc -l", except that the latter is larger by one, which I assume is because windows doesn't count the share folder itself and find does. I would expect these numbers to be different if I was being bitten by some weird windows folder junction point. Windows share folder size: 353GB Samba share folder size: 470GB Can anyone explain this behavior? Mike -- --------Mike at PirateHaven.org-----------------------The_glass_is_too_big--------
On Tue, Apr 17, 2012 at 03:41:59PM -0700, Mike Kelly wrote:> Hi, > > I'm running Samba 3.6.3 on Ubuntu 12.04 (beta). Like many before me, > I'm trying to migrate data from a Windows file server. > > I copied over a share as a test and was a bit surprised when the amount > of space allocated in the file system was over 100GB larger than the > Windows source. I am running on ext4 with "strict allocate = yes" > because I want to be sure that when I turn on quotas, or my users fill > up the file system, that they get the same error experience which they > would get under windows. Or, put another way, software expecting > windows allocate-on-open semantics will get what they expect. > > Now, if I were copying from a Unix file system I'd expect to blame this > on sparse files or hard links. However I'm under the impression that > both of these are exceedingly rare under Windows. Furthermore, I would > expect the Properties dialog box to show useful numbers for "Size" and > "Size on disk". By "useful" I mean that if I were copying data to > another disk of size X, I would expect my data to fit on that disk so > long as these numbers are less than X. > > I'm using robocopy from the windows file server to copy the files. > > According to Windows there are 116,000 files and 2800 folders, and I get > exactly the same values in Unix when running "find /share -type f | wc -l" > and "find /share -type d | wc -l", except that the latter is larger by > one, which I assume is because windows doesn't count the share folder > itself and find does. I would expect these numbers to be different if I > was being bitten by some weird windows folder junction point. > > Windows share folder size: 353GB > Samba share folder size: 470GB > > Can anyone explain this behavior?Can you run a recursive du on both systems to see which directories have a discontinuity ?
On Tue, Apr 17, 2012 at 5:41 PM, Mike Kelly <mike at piratehaven.org> wrote:> I copied over a share as a test and was a bit surprised when the amount > of space allocated in the file system was over 100GB larger than the > Windows source. ?I am running on ext4 with "strict allocate = yes"Do your ntfs and ext4 filesystems have the same block size? also ntfs does support sparse files, and it's more than likely that whatever tool you copied would not preserve that by default if it encountered any.
On Tue, Apr 17, 2012 at 04:06:40PM -0700, Jeremy Allison wrote:> Can you run a recursive du on both systems to see which > directories have a discontinuity ?When using du -sk: windows: 370391711 E:\share SA off: 370932304 /share SA on: 485500380 /share Mike (: -- --------Mike at PirateHaven.org-----------------------The_glass_is_too_big--------
On Wed, Apr 18, 2012 at 06:05:26PM -0700, Mike Kelly wrote:> On Tue, Apr 17, 2012 at 04:06:40PM -0700, Jeremy Allison wrote: > > Can you run a recursive du on both systems to see which > > directories have a discontinuity ? > > When using du -sk: > windows: 370391711 E:\share > SA off: 370932304 /share > SA on: 485500380 /shareThe key you missed here was *recursive* du :-). We know the size is different over all the share, we need to know what directories *within* the share have a different size. Jeremy.