Rodney M. Dyer wrote:
If I request a 100 MB file from the file server and get the following
error on random machines at random times...
From the Visual Studio 2005 install log:
"Error 1335.The cabinet file
'_14314_VC80_PDB_WINSXS_ATLMFC_x64.msm'
required for this installatio
David Bear wrote:
> So I take from this exchange the the surest way to improve openafs
> performance for windows clients would be to convert the windows cache
> manager into a true windows IFS...
If you are talking about raw throughput or transactions per second or
the ability to handle network r
On Mon, Dec 17, 2007 at 02:28:08PM -0500, Jeffrey Altman wrote:
> The Windows Cache Manager cache is Page File backed. If you have the
> memory, it will be loaded in RAM.
>
> But you are missing the point. CIFS access is not faster than disk I/O.
> You are creating a CIFS request, queuing it fo
At 03:12 PM 12/17/2007, Jeffrey Altman wrote:
That is not true at all. If the CIFS interface reads 64KB at a time
and refuses to request the next 64KB until the previous one has been
delivered and the CM is reading 1MB at a time, then there is significant
overhead caused by the CIFS interface.
Rodney M. Dyer wrote:
> At 02:28 PM 12/17/2007, Jeffrey Altman wrote:
>> For each file operation CIFS sends anywhere from three to five requests.
>> As a result there is significant overhead that increases the round trip
>> time and limits the overall throughput.
>
> What I'm getting at is that o
At 02:28 PM 12/17/2007, Jeffrey Altman wrote:
For each file operation CIFS sends anywhere from three to five requests.
As a result there is significant overhead that increases the round trip
time and limits the overall throughput.
What I'm getting at is that once a 100 MB file is opened and is
Rodney M. Dyer wrote:
> At 10:46 AM 12/17/2007, Jeffrey Altman wrote:
>> While AFS on UNIX is limited by the performance of Rx/UDP, on Windows
>> we are actually limited by the CIFS/SMB implementation. A native
>> redirector will be a big win here.
>
> Am I wrong here in thinking that the code fo
At 10:46 AM 12/17/2007, Jeffrey Altman wrote:
While AFS on UNIX is limited by the performance of Rx/UDP, on Windows we
are actually limited by the CIFS/SMB implementation. A native redirector
will be a big win here.
Am I wrong here in thinking that the code for CIFS/SMB access is already
fas
Lars Schimmer wrote:
> Jeffrey Altman wrote:
> I like to mention my/our side of view:
> The OpenAFS windows clients went better and faster from release to
> release. I still remember old 1.3.x times, in this view, the 1.5.28 is
> really far better and faster.
> And I don't want to smaller the work
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeffrey Altman wrote:
> Rodney M. Dyer wrote:
>> I understand this, however you need to realize where I'm coming from.
>> We support professors who have research projects that run into the
>> millions of dollars. Many times these people don't know an
> Its hideous. I hope no one asks for it.
Of course. But look at my alternatives:
1) Continue to use krb524 - No Go
K4 is dead and dangerous. Removing our last uses of it
is how I got here in the first place.
2) Track down all the instances we have used this way
(successfully under
John Hascall wrote:
>> Or is that just too hideous?
>
> Well, on the very-off-chance that anyone else wants it,
> I will announce that I have made this work. Anyone is
> welcome to it, with absolutely no warranty, of course :)
Its hideous. I hope no one asks for it.
smime.p7s
Description:
> I'm presuming the problem is that the ticket inside of the
> token has sysadmin/[EMAIL PROTECTED] inside of it
> even though aklog was able to convert that to sysadmin.asw
> and thus correctly to the 'AFS ID 99940' (which is sysadmin.asw
> in the pts db).
>
> Would it work to modify the KDC su
On Dec 12, 2007, at 11:06 PM, Jeffrey Altman wrote:
...Stupid things like re-using objects that were recently accessed
because
the queues did not track objects in the order of most recent use.
Being
forced to read data or directory entries from the file server that was
just written by the
On Dec 12, 2007, at 10:21 PM, Christopher D. Clausen wrote:
I know this is isn't a useful data point, but to my knowledge, none of
the AFS servers that I maintain have lost important data due to a
fault
in AFS. Yes, some test data was lost, but that is exactly why a
"professional" sysadmin
At 11:21 PM 12/12/2007, Jeffrey Altman wrote:
Ok. Now that we are all friends again can we get back to the business
of making OpenAFS a better product?
Absolutely. I was never trying to be scornful at all. As you all know, I
have a deep love and respect for AFS, and we have been using it fa
Christopher D. Clausen wrote:
> Perhaps some of these millions of dollars from these research projects
> can go into testing to provide a "better" AFS client that is both fast
> AND reliable.
Rodney doesn't control the money. It would be wonderful if the cost of
AFS was paid for as part of the
Rodney M. Dyer wrote:
> I understand this, however you need to realize where I'm coming from.
> We support professors who have research projects that run into the
> millions of dollars. Many times these people don't know anything about
> where their data files are being saved when they choose "Fi
Rodney M. Dyer <[EMAIL PROTECTED]> wrote:
> At 05:26 PM 12/12/2007, Jeffrey Altman wrote:
>> I disagree. We need more resources for testing a broader range of
>> scenarios than we currently have available. The performance
>> improvements must be implemented or you absolutely should go find
>> som
On Dec 12, 2007 3:37 PM, Douglas E. Engert <[EMAIL PROTECTED]> wrote:
>
>
> John Hascall wrote:
> >> John Hascall wrote:
> >>> Would it work to modify the KDC such that when it hands out
> >>> an afs/@REALM ticket for a TGT with a client name that
> >>> is in the sconv table (like my sysadmin/[EMA
At 05:26 PM 12/12/2007, Jeffrey Altman wrote:
I disagree. We need more resources for testing a broader range of
scenarios than we currently have available. The performance
improvements must be implemented or you absolutely should go find
something else to use.
If we can't get to the point wher
Rodney M. Dyer wrote:
> Well mine are clearly data integrity and reliability. Speed is
> important, but speed without some guarantee of data integrity is
> pointless. Over the years of using AFS on Windows, we've seen more
> issues related to data integrity than we should have seen compared to
>
At 04:25 PM 12/12/2007, Jeffrey Altman wrote:
John Hascall wrote:
> And it's not clear to me how much
> longer AFS will be our main filesystem.
What would be needed to keep AFS as your main file system?
Well mine are clearly data integrity and reliability. Speed is important,
but speed witho
Jeffrey Altman wrote:
Douglas E. Engert wrote:
Sounds like the tail waging the dog. There are KDCs used with AFS
that are not modifiable, and don't support any k4. You don't want to
fiddle with the K5 protocols either. the Its time to get AFS 'k5-izes'.
Yes, it would be lovely if AFS was 100
John Hascall wrote:
>> Douglas E. Engert wrote:
> Sounds like the tail waging the dog. There are KDCs used with AFS
> that are not modifiable, and don't support any k4. You don't want to
> fiddle with the K5 protocols either. the Its time to get AFS 'k5-izes'.
>
Yes, it would be
> Douglas E. Engert wrote:
> >>> Sounds like the tail waging the dog. There are KDCs used with AFS
> >>> that are not modifiable, and don't support any k4. You don't want to
> >>> fiddle with the K5 protocols either. the Its time to get AFS 'k5-izes'.
> >> Yes, it would be lovely if AFS was 100%
Douglas E. Engert wrote:
>>> Sounds like the tail waging the dog. There are KDCs used with AFS
>>> that are not modifiable, and don't support any k4. You don't want to
>>> fiddle with the K5 protocols either. the Its time to get AFS 'k5-izes'.
>>
>> Yes, it would be lovely if AFS was 100% K5.
>
John Hascall wrote:
John Hascall wrote:
Would it work to modify the KDC such that when it hands out
an afs/@REALM ticket for a TGT with a client name that
is in the sconv table (like my sysadmin/[EMAIL PROTECTED])
that it 'K4-izes' that name (to sysadmin/asw in this case) in the
returned ticke
> John Hascall wrote:
> > Would it work to modify the KDC such that when it hands out
> > an afs/@REALM ticket for a TGT with a client name that
> > is in the sconv table (like my sysadmin/[EMAIL PROTECTED])
> > that it 'K4-izes' that name (to sysadmin/asw in this case) in the
> > returned ticket?
John Hascall wrote:
Would it work to modify the KDC such that when it hands out
an afs/@REALM ticket for a TGT with a client name that
is in the sconv table (like my sysadmin/[EMAIL PROTECTED])
that it 'K4-izes' that name (to sysadmin/asw in this case) in the
returned ticket? (Thus obviating
> > Russ Allbery wrote:
> > > John Hascall <[EMAIL PROTECTED]> writes:
> > >> I'm sure I must be doing something embarrassingly stupid here,
> > >> but I just can't figure out why this script is not able to
> > >> access the files in AFS that it should be able to.
> > >> Default principal: sysadm
> Russ Allbery wrote:
> > John Hascall <[EMAIL PROTECTED]> writes:
> >> I'm sure I must be doing something embarrassingly stupid here,
> >> but I just can't figure out why this script is not able to
> >> access the files in AFS that it should be able to.
> >> Default principal: sysadmin/[EMAIL
Russ Allbery wrote:
> John Hascall <[EMAIL PROTECTED]> writes:
>
>> I'm sure I must be doing something embarrassingly stupid here,
>> but I just can't figure out why this script is not able to
>> access the files in AFS that it should be able to.
>
> [...]
>
>> Default principal: sysadmin/[EMAIL
John Hascall <[EMAIL PROTECTED]> writes:
> I'm sure I must be doing something embarrassingly stupid here,
> but I just can't figure out why this script is not able to
> access the files in AFS that it should be able to.
[...]
> Default principal: sysadmin/[EMAIL PROTECTED]
There's a hard-coded
I'm sure I must be doing something embarrassingly stupid here,
but I just can't figure out why this script is not able to
access the files in AFS that it should be able to.
#!/usr/afsws/bin/pagsh
PATH=$PATH:/usr/local/bin:/usr/athena/bin:/usr/afsws/bin ; export PATH
KEYTBFILE=/acropolis/etc/keyta
35 matches
Mail list logo
