samba - Mar 2005 - Samba and Preallocated Files

A question about capturing videos to a Samba  share... 

When Apple's Final Cut Pro captures video files, it  pre-allocates file
space
on the destination volume. 

If you capture to a  local volume that's physically attached to a Macintosh,
or if you capture to a  network volume via AFP (Apple File Sharing Protocol), 
you can see that Final Cut  instantly creates a file of the anticipated size 
on the destination volume at  the moment just before capture begins (the 
anticipated size is based on the  maximum capture time limit set by a user). 

However, when capturing  videos to a Windows or Samba share, Final Cut 
actually will write out "dummy  data" to a file, and then presumably
it replaces the
dummy data with real data  as the capture moves along. 

Effectively, this makes Samba and Windows  shares useless for capturing Final 
Cut videos. Because, for instance, if you  expect to capture a 20-minute DV 
clip, it will take approximately 10 minutes to  create the pre-allocated file 
before capturing even begins -- even when you are  connecting via a dedicated 
Gigabit Ethernet link. The process seems to chug  along unbelievably slowly. 
And if you were capturing uncompressed video (which  has about 5x the data rate 
of DV video) well, the wait would be interminable.  

Can anybody on this list see a way to allow Final Cut to instantly  create 
that pre allocated file space that it wants to create on a Samba share?  Are 
their any Samba settings that could make this possible? It would be a coup  for 
Samba! 

BTW, Apple's IMovie doesn't go through this pre allocation  business.
But,
alas, IMovie doesn't capture timecode data, so Final Cut users  who want to
work
with Samba shares can't simply switch to IMovie for capturing  their videos.

Hoping for an insightful reply, 
Andy Liebman

On Tue, Mar 15, 2005 at 06:31:19AM -0500, AndyLiebman@aol.com
wrote:
> A question about capturing videos to a Samba  share... 
> 
> When Apple's Final Cut Pro captures video files, it  pre-allocates file
space
> on the destination volume. 
> 
> If you capture to a  local volume that's physically attached to a
Macintosh,
> or if you capture to a  network volume via AFP (Apple File Sharing
Protocol),
> you can see that Final Cut  instantly creates a file of the anticipated
size
> on the destination volume at  the moment just before capture begins (the 
> anticipated size is based on the  maximum capture time limit set by a
user).
> 
> However, when capturing  videos to a Windows or Samba share, Final Cut 
> actually will write out "dummy  data" to a file, and then
presumably it replaces the
> dummy data with real data  as the capture moves along. 
> 
> Effectively, this makes Samba and Windows  shares useless for capturing
Final
> Cut videos. Because, for instance, if you  expect to capture a 20-minute DV
> clip, it will take approximately 10 minutes to  create the pre-allocated
file
> before capturing even begins -- even when you are  connecting via a
dedicated
> Gigabit Ethernet link. The process seems to chug  along unbelievably
slowly.
> And if you were capturing uncompressed video (which  has about 5x the data
rate
> of DV video) well, the wait would be interminable.  
> 
> Can anybody on this list see a way to allow Final Cut to instantly  create 
> that pre allocated file space that it wants to create on a Samba share? 
Are
> their any Samba settings that could make this possible? It would be a coup 
for
> Samba! 
> 
> BTW, Apple's IMovie doesn't go through this pre allocation 
business. But,
> alas, IMovie doesn't capture timecode data, so Final Cut users  who
want to work
> with Samba shares can't simply switch to IMovie for capturing  their
videos.
That's a Mac client issue. We do support "sparse" pre-allocation
on the
server side. I'd raise it as a bug with Apple.

Jeremy.

In a message dated 3/15/2005 1:00:38 P.M. Eastern Standard Time,  
jra@samba.org writes:

On Tue,  Mar 15, 2005 at 06:31:19AM -0500, AndyLiebman@aol.com
wrote:
> A  question about capturing videos to a Samba  share... 
> 
>  When Apple's Final Cut Pro captures video files, it  pre-allocates
file
space 
> on the destination volume. 
> 
> If you capture to  a  local volume that's physically attached to a 
Macintosh, 
> or if  you capture to a  network volume via AFP (Apple File Sharing 
Protocol),  
> you can see that Final Cut  instantly creates a file of the  anticipated 
size 
> on the destination volume at  the moment just  before capture begins (the 
> anticipated size is based on the   maximum capture time limit set by a 
user). 
> 
> However, when  capturing  videos to a Windows or Samba share, Final Cut 
>  actually will write out "dummy  data" to a file, and then
presumably it
replaces the 
> dummy data with real data  as the capture moves  along. 
> 
> Effectively, this makes Samba and Windows   shares useless for capturing 
Final 
> Cut videos. Because, for instance,  if you  expect to capture a 20-minute 
DV 
> clip, it will take  approximately 10 minutes to  create the pre-allocated 
file 
>  before capturing even begins -- even when you are  connecting via a  
dedicated 
> Gigabit Ethernet link. The process seems to chug   along unbelievably 
slowly. 
> And if you were capturing uncompressed  video (which  has about 5x the data
rate 
> of DV video) well, the  wait would be interminable.  
> 
> Can anybody on this list  see a way to allow Final Cut to instantly  create
> that pre  allocated file space that it wants to create on a Samba share?  
Are  
> their any Samba settings that could make this possible? It would be a  coup
 for 
> Samba! 
> 
> BTW, Apple's IMovie doesn't  go through this pre allocation 
business. But,
> alas, IMovie  doesn't capture timecode data, so Final Cut users  who
want
to work  
> with Samba shares can't simply switch to IMovie for capturing   their 
videos. 

That's a Mac client issue. We do support "sparse"  pre-allocation
on the
server side. I'd raise it as a bug with  Apple.

Jeremy.


Jeremy, 
 
Isn't the Mac Samba Client compiled from a stock Samba samba.org source  
code? And if so, shouldn't it behave as any other Samba client. Or is Apple 
doing
their own thing with the Samba client? 
 
I've been Googling for information to see if it's possible to compile my
own
Samba for OS X and haven't come up with much. 
 
If it IS an Apple bug, I would bet "dollars to doughnuts" that Apple
will
quietly neglect the issue. In my experience with the company, they don't
want to
 do ANYTHING that will help non-Apple products compete with Apple storage  
devices. They will simply leave it broken. 
 
That's not to say that it's the Samba Team's job to fix it. I've
just been
dealing with Apple Final Cut Pro developers for a long time and I know of  what 
I speak! All I've gotten out of them is "it's the Quicktime API
that's
responsible, and they'll have to change Quicktime to change the behavior
when
writing to a Samba share."
 
Does that ring true to you? 
 
Have you heard of XSan and XServe RAID? 
 
Regards, 
Andy Liebman