Corruption problems have nothing to do with file sizes.
I remember that I postet a problem on November, 9th 2001 ( oplock problem ).
I could create inconsistent data in a file on a samba share because of locking problems.
This was a real corruption of data even if the file was small.
As Jeremy
David Collier-Brown -- Customer Engineering wrote:
There are also some sharable filesystems that could
result in two sambae sharing the same files: supposedy
my employer sells one (:-))
:-)
Yes, I considered NFS, but only as as way to allow the two
Sambae to be on separate machines and so
Steve Langasek wrote:
If oplock support is disabled, yes, you can expect two Samba
installations to play nicely with locks on the same set of files. If
oplocking is enabled, it might also be possible to make them behave,
though this would at least require some symlink magic.
There
Reading through Jeremy's eagerly awaited discourse on oplocks/share
modes/locking, I read this bit :
... if you need simultaneous
file access from a Windows and UNIX client you *must* have an
application that is written to lock records correctly on both
sides. Few applications are written
On Thu, Oct 24, 2002 at 11:48:53AM -0700, Ben Johnson wrote:
samba and vi aren't written to cooperate for example. should these be
written to cooperate? that would mean the authors of each would have to
cooperate. it seems like it would be easier to have the kernel force
cooperation.
If
On Thu, Oct 24, 2002 at 06:29:23PM +, [EMAIL PROTECTED] wrote:
POSIX has mandatory locks that are kernel enforced. Almost no application
uses them and they also require permission changes on the file.
hm. I've never heard of them. time to crack a book.
If your applications aren't
On Thu, Oct 24, 2002 at 11:24:38AM -0700, Ben Johnson wrote:
Thanks for the explanation.
I never understood why *nix doesn't implement some kind of file locking
mechanism that actually enforces file locks. I can see why the
traditional advisory locking semantics are useful, but wouldn't a
Thanks for the explanation.
I never understood why *nix doesn't implement some kind of file locking
mechanism that actually enforces file locks. I can see why the
traditional advisory locking semantics are useful, but wouldn't a
locking system that is actually enforced by the kernel potentially
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 24 Oct 2002, Rashkae wrote:
Has there ever been an explanation found for the brief rash of people
who had tidbits of Samba log file data inserted in their network shared
files when sharing over a Samba server?? If indeed that problem was
I guess what I am thinking about is how difficult it seems to be for
programs to actually cooperate with one another well enough to avoid
corrupting files. I know from experience that using flock() effectively
for making anything trustworthy that's more complicated than creating
lock files can be
On Thu, Oct 24, 2002 at 01:59:42PM -0700, Ben Johnson wrote:
A kernel supported api for locking files (maybe with timeouts and mutex
values) that actually enforced the file locks, instead of relying on
applications to be friendly to one another might (I think would) make
programming some user
heh heh... so maybe I have yet more reading to do. sorry.
One thing I don't get though Is Samba written to allow poorly
written applications that are accessing the files through Samba to
corrupt the files they share? These poorly written database apps for
instance, Access, Paradox, and
On Thu, Oct 24, 2002 at 02:41:42PM -0700, Ben Johnson wrote:
They apparently are able to
corrupt files on the Samba server when they don't honor oplock breaks.
Is that true? How does it happen?
It's a client kernel redirector bug or a problem with network drivers or
network hardware. Nothing
On Thu, Oct 24, 2002 at 07:34:19AM +0200, Walter Mautner wrote:
As far as I know, oplocks are extensions to common file locks.
In fact, whenever a oplock is set, also a conventional lock
request is sent to the underlying non-smb locking system, and only
if this one doesn't report it as
John, Please ignore this question from someone who probaby doesn't know
enough to make sound statements, and who hasn't really followed the list
closely lately
Has there ever been an explanation found for the brief rash of people who
had tidbits of Samba log file data inserted in their
On Thu, Oct 24, 2002 at 08:35:02PM +0200, Jelmer Vernooij wrote:
On Thu, Oct 24, 2002 at 05:48:49PM +, [EMAIL PROTECTED] wrote about 'Re: [Samba]
Re: How Samba let us down':
Ok, as promised, a brief explaination of oplocks, share modes
and locking.
[...]
Mind if I add
On Thu, Oct 24, 2002 at 05:48:49PM +, [EMAIL PROTECTED] wrote about 'Re: [Samba]
Re: How Samba let us down':
Ok, as promised, a brief explaination of oplocks, share modes
and locking.
[...]
Mind if I add this to the docs?
Jelmer
Ok, as promised, a brief explaination of oplocks, share modes
and locking.
When a client opens a file it can request an oplock or file
lease. This is (to simplify a bit) a guarentee that no one else
has the file open simultaneously. It allows the client to not
send any updates on the file to the
On Thu, Oct 24, 2002 at 01:08:10PM +1000, Matthew Hannigan wrote:
On Thu, Oct 24, 2002 at 02:10:14AM +, [EMAIL PROTECTED] wrote:
On Wed, Oct 23, 2002 at 09:02:03PM -0500, Steve Langasek wrote:
On Thu, Oct 24, 2002 at 11:38:55AM +1000, Matthew Hannigan wrote:
I have read in the
On Thu, 24 Oct 2002, Rashkae wrote:
John, Please ignore this question from someone who probaby doesn't know
enough to make sound statements, and who hasn't really followed the list
closely lately
I choose to help, not ignore.
Has there ever been an explanation found for the brief rash
On Thu, Oct 24, 2002 at 06:36:10PM +, [EMAIL PROTECTED] wrote:
On Thu, Oct 24, 2002 at 08:35:02PM +0200, Jelmer Vernooij wrote:
On Thu, Oct 24, 2002 at 05:48:49PM +, [EMAIL PROTECTED] wrote about 'Re:
[Samba] Re: How Samba let us down':
Ok, as promised, a brief explaination
On Thu, Oct 24, 2002 at 10:44:28AM -0500, Steve Langasek wrote:
On Thu, Oct 24, 2002 at 01:08:10PM +1000, Matthew Hannigan wrote:
And Solaris? At least they're autoconfigured to assume kernel oplocks
according to testparm, and the docs say this is done only if the support
is there.
On Fri, Oct 25, 2002 at 11:04:43AM +1000, Matthew Hannigan wrote:
On Thu, Oct 24, 2002 at 10:44:28AM -0500, Steve Langasek wrote:
On Thu, Oct 24, 2002 at 01:08:10PM +1000, Matthew Hannigan wrote:
And Solaris? At least they're autoconfigured to assume kernel oplocks
according to testparm,
On Thu, Oct 24, 2002 at 08:15:08PM -0500, Steve Langasek wrote:
Ah, but it doesn't really matter *what* the value of kernel oplocks is,
if you don't have kernel support for oplocks. :) The only other option
My bad, I was confusing options 'op locks' and 'kernel op locks'
Still, it would be
On Wed, Oct 23, 2002 at 05:25:56AM -0700, Jay Ts wrote:
The corruption might be related to oplocks. I'm doing
File corruption is treated as a drop everything - priority
1 bug in Samba. If this were a generic problem known with
2.2.6 we'd be issuing a patch *immediately*.
That's not to say
Jeremy Allison ([EMAIL PROTECTED]) wrote:
Jay Ts wrote:
The corruption might be related to oplocks. I'm doing
Just to keep myself out of more trouble today, I'd like
to point out that I didn't write the above. ;-)
File corruption is treated as a drop everything - priority
1 bug in
Title: RE: [Samba] Re: How Samba let us down
Here at Tricord, we run Samba through some pretty intense tests, as well. Since we are a file system producer, we focus on corruption bugs. We haven't found any in Samba, other than a rather famous Microsoft Word bug that also occurs on Windows
John H Terpstra wrote:
For the record, I thouroughly test samba pre-releases before we ever ship.
To the best of my knowledge, NOT ONE version of samba we have released
ever CAUSED (or resulted in) file/data corruption. If I sound defensive -
that's is exactly correct because file corruption
Esh, Andrew wrote:
Here at Tricord, we run Samba through some pretty intense tests, as well.
Since we are a file system producer, we focus on corruption bugs. We haven't
found any in Samba,
Since I've been curious about this anyway, I might go ahead and check:
Do you (And J. Terpstra, and
Title: RE: [Samba] Re: How Samba let us down
We regularly do large file Copy-Paste tests with files between 30G and 60G. We have yet to see a problem.
Tricord's market is Network Attached Storage, and our product is a file system. Samba is the main interface between our market and our file
On Wed, 23 Oct 2002, Jay Ts wrote:
Esh, Andrew wrote:
Here at Tricord, we run Samba through some pretty intense tests, as well.
Since we are a file system producer, we focus on corruption bugs. We haven't
found any in Samba,
Since I've been curious about this anyway, I might go ahead
On Wed, Oct 23, 2002 at 02:34:28PM -0500, Esh, Andrew wrote:
We regularly do large file Copy-Paste tests with files between 30G and 60G.
We have yet to see a problem.
Tricord's market is Network Attached Storage, and our product is a file
system. Samba is the main interface between our
On Wed, 23 Oct 2002, Jay Ts wrote:
Esh, Andrew wrote:
Here at Tricord, we run Samba through some pretty intense tests, as well.
Since we are a file system producer, we focus on corruption bugs. We haven't
found any in Samba,
Since I've been curious about this anyway, I might go ahead and
On Thu, Oct 24, 2002 at 06:36:26AM +0930, Richard Sharpe wrote:
In my opinion, while it is possible to do what you say, that is not how
you will detect corruption. Corruption of the sort you mention will be
detected very quickly in normal tests.
The sort of corruption I think we should
On Wed, 23 Oct 2002, Jay Ts wrote:
John H Terpstra wrote:
For the record, I thouroughly test samba pre-releases before we ever ship.
To the best of my knowledge, NOT ONE version of samba we have released
ever CAUSED (or resulted in) file/data corruption. If I sound defensive -
that's
John H Terpstra wrote:
Both ways. Remember file/data corruption is a death issue. We do NOT ship
if we see it is broken and we are PARANOID about integrity. Also, remember
that just because it works does not mean it is not broken. Oops, did I say
PARANOID?
[...]
Also remember our unique
On Wed, Oct 23, 2002 at 01:26:15PM -0700, Jay Ts wrote:
John H Terpstra wrote:
Both ways. Remember file/data corruption is a death issue. We do NOT ship
if we see it is broken and we are PARANOID about integrity. Also, remember
that just because it works does not mean it is not broken.
As I understand it, concurrent access from SMB clients and NFS clients
(or other UNIX processes) can cause corruption when oplocks is turned on
(unless your UNIX supports kernel oplocks and you use them - only some
Linux and Irix versions support them I believe). Turning off oplocks
might
On Wed, Oct 23, 2002 at 02:14:41PM -0700, Marc Jacobsen wrote:
This next statement from John Terpstra seems a bit strong to me, see the
counter example below from just a few weeks ago. Not to badmouth John,
or Samba, just to add some more information to the conversation.
What about this
- Original Message -
From: Most of you
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, October 23, 2002 10:14 PM
Subject: Re: [Samba] Re: How Samba let us down
etc etc
Well this one certainly roused you all.
Must it be the case that you all jump in to reply to this unhelpful
Philip Burrow wrote:
- Original Message -
From: Most of you
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, October 23, 2002 10:14 PM
Subject: Re: [Samba] Re: How Samba let us down
etc etc
Well this one certainly roused you all.
Must it be the case that you all
, and is voluntary.
- John T.
- Original Message -
From: Most of you
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, October 23, 2002 10:14 PM
Subject: Re: [Samba] Re: How Samba let us down
etc etc
Well this one certainly roused you all.
Must it be the case that you
: [EMAIL PROTECTED] [mailto:samba-admin;lists.samba.org]On
Behalf Of John H Terpstra
Sent: Wednesday, October 23, 2002 4:39 PM
To: Philip Burrow
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [Samba] Re: How Samba let us down
On Wed, 23 Oct 2002, Philip Burrow wrote:
Philip,
Those of us who work
On Wed, Oct 23, 2002 at 02:14:41PM -0700, Marc Jacobsen wrote:
[ ... ]
Similarly, record locks and share mode locks from SMB clients are both
ignored by NFS clients/other UNIX processes (with the possible exception
of newer Linux systems, they might actually enforce share mode locks).
In
On Thu, Oct 24, 2002 at 11:38:55AM +1000, Matthew Hannigan wrote:
On Wed, Oct 23, 2002 at 02:14:41PM -0700, Marc Jacobsen wrote:
[ ... ]
Similarly, record locks and share mode locks from SMB clients are both
ignored by NFS clients/other UNIX processes (with the possible exception
of
On Thu, Oct 24, 2002 at 02:10:14AM +, [EMAIL PROTECTED] wrote:
On Wed, Oct 23, 2002 at 09:02:03PM -0500, Steve Langasek wrote:
On Thu, Oct 24, 2002 at 11:38:55AM +1000, Matthew Hannigan wrote:
I have read in the docs that Samba locks and Unix locks
_DO_ notice each other, with the
On Thu, Oct 24, 2002 at 11:38:55AM +1000, Matthew Hannigan wrote:
..
I did have a look at the docs really, but
textdocs/UNIX-SMB.txt for instance says that Unix has no
simple way of implementing opportunistic locking, and
currently Samba has no support for it.
Which is out of date I
47 matches
Mail list logo
