Re: [Samba] Samba and Preallocated Files

2005-03-15 Thread Jeremy Allison
On Tue, Mar 15, 2005 at 06:13:17PM -0500, [EMAIL PROTECTED] wrote:
>  
> 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? 

Apple maintains their own code - based originally on the FreeBSD smbfs code
I believe.

> 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. 

No, that's not my experience with Conrad - he's the Apple developer in 
charge of their CIFS client. But there's only one of him and he has
a schedule.

> 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? 

Either Quicktime could be fixed, or the Apple CIFS client could be fixed.
The server isn't doing anything wrong - it's being asked to write data and
so it does.

> Have you heard of XSan and XServe RAID? 

I've heard of them, yes.

Jeremy.
-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/listinfo/samba


Re: [Samba] Samba and Preallocated Files

2005-03-15 Thread AndyLiebman
 
In a message dated 3/15/2005 1:00:38 P.M. Eastern Standard Time,  
[EMAIL PROTECTED] writes:

On Tue,  Mar 15, 2005 at 06:31:19AM -0500, [EMAIL PROTECTED] 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
-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/listinfo/samba


Re: [Samba] Samba and Preallocated Files

2005-03-15 Thread Jeremy Allison
On Tue, Mar 15, 2005 at 06:31:19AM -0500, [EMAIL PROTECTED] 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.
-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/listinfo/samba


[Samba] Samba and Preallocated Files

2005-03-15 Thread AndyLiebman
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  

-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/listinfo/samba