Custom Search
|
Date: December 31, 2006
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<45942BCF.50904@xxxxxxx>
References:
<45942BCF.50904@xxxxxxx>
> I was reading the thread: > > [linux-cifs-client] Re: io blksize problem with cifs > > (Regarding the issue with cifs share w/ greater than N number of files > puking with an error like: reading directory /mnt/archive: Invalid > argument.) > > I lost the thread, and was wondering if there was a work-around for this > issue? I though that was the issue (blksize was set incorrectly, and cifs was returning an expected error condition on filldir back to the user incorrectly) was fixed in the Fedora kernel, and it should not be an issue in mainline. For mainline: http://master.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7ca85ba752e521f1b5ead1f3b91c562cc3910c7b fixed the immediate issue, and then http://master.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5fe14c851efedf95b0e7652a3a7b93ec899d1599 set the blocksize properly. Not sure how to workaround this - but directories of less than about 120 entries were fine. Steve French Senior Software Engineer Linux Technology Center - IBM Austin phone: 512-838-2294 email: sfrench at-sign us dot ibm dot com
Date: December 31, 2006
From: Jeremy Allison <jra@xxxxxxxxx>
In-reply-to:
<004801c72d18$85f305f0$d300a8c0@LAZYBOY
>
References:
<004801c72d18$85f305f0$d300a8c0@LAZYBOY
>
On Sun, Dec 31, 2006 at 03:16:14PM -0500, Jerome Whelan wrote: > Problem Symptoms: > The "ls" command cannot list directory content of a remote CIFS directory > when the directory holds more than 125 user files + dot + dotdot for a > total of 127 files. Fewer files works OK, but with 128 files or more I get > "ls: reading directory /mnt/test/: Invalid argument" > > I'm guessing this is associated with the mounting, since the remote CIFS > directory CAN be manipulated normally by Windows-XP clients, AND the Linux > box can list local disk directories containing thousands of files. > > Any recommendations that will allow full access to CIFS server with large > number of files in each directory? > > ---------------------------------------------------------------- > > System is Fedora Core 6 with these versions installed > samba-common-3.0.23c-2 > samba-3.0.23c-2 > samba-client-3.0.23c-2 > system-config-samba-1.2.35-1.1 > > Remote filesystem is Buffalo TeraServer 1 TB model > and I mount the remote filesystem using command > > # mount -t cifs \\\\nas236\\test /mnt/test I'm guessing this is the Trans2findnext bug that was in earlier versions of 3.0.x Samba servers that has since been fixed. Can you find out what version of Samba is running on the Buffalo TeraServer ? Jeremy.
Date: December 31, 2006
From: "Jerome Whelan" <whelanjh@xxxxxxxxxxx>
Problem Symptoms:The "ls" command cannot list directory content of a remote CIFS directory when the directory holds more than 125 user files + dot + dotdot for a total of 127 files. Fewer files works OK, but with 128 files or more I get "ls: reading directory /mnt/test/: Invalid argument"
I'm guessing this is associated with the mounting, since the remote CIFS directory CAN be manipulated normally by Windows-XP clients, AND the Linux box can list local disk directories containing thousands of files.
Any recommendations that will allow full access to CIFS server with large number of files in each directory?
---------------------------------------------------------------- System is Fedora Core 6 with these versions installed samba-common-3.0.23c-2 samba-3.0.23c-2 samba-client-3.0.23c-2 system-config-samba-1.2.35-1.1 Remote filesystem is Buffalo TeraServer 1 TB model and I mount the remote filesystem using command # mount -t cifs \\\\nas236\\test /mnt/test
Date: December 29, 2006
From: Unknown <unknown@xxxxxxxxxxxxxxx>
BANNED FILENAME ALERT Your message to: kvaidya@xxxxxxxxxxxxxxxx was blocked by our Spam Firewall. The email you sent with the following subject has NOT BEEN DELIVERED: Subject: Re: Your details An attachment in that mail was of a file type that the Spam Firewall is set to block.
Reporting-MTA: dns; spamkill.zenithinfotech.com
Received-From-MTA: smtp; spamkill.zenithinfotech.com ([127.0.0.1])
Arrival-Date: Fri, 29 Dec 2006 15:02:43 -0800 (PST)
Final-Recipient: rfc822; kvaidya@zenith-india.com
Action: failed
Status: 5.7.1
Diagnostic-Code: smtp;
550 5.7.1 Message content rejected, id=32269-01-35 - BANNED:
icq_number6.pif
Last-Attempt-Date: Fri, 29 Dec 2006 15:02:43 -0800 (PST)
Received: from zenith-india.com (unknown [202.54.156.157])
by spamkill.zenithinfotech.com (Spam Firewall) with ESMTP id DCC5E11FC62
for <kvaidya@xxxxxxxxxxxxxxxx>; Fri, 29 Dec 2006 15:02:40 -0800 (PST)
From: linux-cifs-client@xxxxxxxxxxxxxxx
To: kvaidya@xxxxxxxxxxxxxxxx
Subject: Re: Your details
Date: Sat, 30 Dec 2006 04:34:56 +0530
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_0016----=_NextPart_000_0016"
X-Priority: 3
X-MSMail-Priority: Normal
Message-Id: <20061229230240.DCC5E11FC62@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: December 27, 2006
From: Q <qwerty0987654321@xxxxxxx>
In-reply-to:
<4547B6B0.3040405@xxxxxxxxxx>
References:
<4547B6B0.3040405@xxxxxxxxxx>
Steve French wrote:
NFS submounts are explained in the mail thread and patches starting here http://linux-nfs.org/pipermail/nfsv4/2006-April/004079.htmlInteresting ... it may be easier than we thought to finish the last few pieces of cifs dfs_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Some news about subj. I've almost done it using NFS submount approach. Now It can mount and follow DFS link. Though I've not started unmount part for submounts yet.If someone wish to play with not completed DFS support, I can send patch to cifs module from 2.6.19.1 kernel.
-- Best regards, ------------------------- Igor Mammedov, niallain "at" gmail.com
Date: December 24, 2006
From: Randy Dunlap <randy.dunlap@xxxxxxxxxx>
In-reply-to:
<Pine.LNX.4.64.0612231152360.3671@xxxxxxxxxxxxxx>
References:
<458BEB9D.8030709@xxxxxxxx> <20061222223034.b29aeb5f.khali@xxxxxxxxxxxx> <Pine.LNX.4.64.0612221615430.3671@xxxxxxxxxxxxxx> <Pine.LNX.4.64.0612231004270.3671@xxxxxxxxxxxxxx> <20061223114458.30722de7.randy.dunlap@xxxxxxxxxx> <Pine.LNX.4.64.0612231152360.3671@xxxxxxxxxxxxxx>
On Sat, 23 Dec 2006 12:06:43 -0800 (PST) Linus Torvalds wrote: > > > On Sat, 23 Dec 2006, Randy Dunlap wrote: > > > > BTW, reiserfs has similar build problems: it uses clear_page_dirty() > > so it won't build. > > Not any more. I fixed that one (very different issue, btw: it's not > actually doign writeout, it actually wanted to cancel IO on truncated > buffers. > > However, it's certainly possible that my fix hasn't mirrored out yet, I > pushed it just a couple of hours ago. So if you want to test it, here are > the two commits in question.. > > (The "cancel_dirty_page()" cleanup is needed not just to do reiserfs as a > module, it's also to make it more robust against reiserfs possibly feeding > that function with strange pages, and to match the other related functions > in the accounting functions). > > Len Brown tested the reiserfs changes, and claims that it was all good, > but if somebody wants to run fsx-linux or some other filesystem stress > testing tool that actually tests shared mmap (and truncate), that would be > really appreciated. I ran fsx-linux on it for one hour... with no problems reported. --- ~Randy
Date: December 23, 2006
From: Linus Torvalds <torvalds@xxxxxxxx>
In-reply-to:
<20061223114458.30722de7.randy.dunlap@xxxxxxxxxx>
References:
<458BEB9D.8030709@xxxxxxxx> <20061222223034.b29aeb5f.khali@xxxxxxxxxxxx> <Pine.LNX.4.64.0612221615430.3671@xxxxxxxxxxxxxx> <Pine.LNX.4.64.0612231004270.3671@xxxxxxxxxxxxxx> <20061223114458.30722de7.randy.dunlap@xxxxxxxxxx>
On Sat, 23 Dec 2006, Randy Dunlap wrote:
>
> BTW, reiserfs has similar build problems: it uses clear_page_dirty()
> so it won't build.
Not any more. I fixed that one (very different issue, btw: it's not
actually doign writeout, it actually wanted to cancel IO on truncated
buffers.
However, it's certainly possible that my fix hasn't mirrored out yet, I
pushed it just a couple of hours ago. So if you want to test it, here are
the two commits in question..
(The "cancel_dirty_page()" cleanup is needed not just to do reiserfs as a
module, it's also to make it more robust against reiserfs possibly feeding
that function with strange pages, and to match the other related functions
in the accounting functions).
Len Brown tested the reiserfs changes, and claims that it was all good,
but if somebody wants to run fsx-linux or some other filesystem stress
testing tool that actually tests shared mmap (and truncate), that would be
really appreciated.
Linus
--
commit 8368e328dfe1c534957051333a87b3210a12743b
Author: Linus Torvalds <torvalds@xxxxxxxxxxxxxx>
Date: Sat Dec 23 09:25:04 2006 -0800
Clean up and export cancel_dirty_page() to modules
Make cancel_dirty_page() act more like all the other dirty and writeback
accounting functions: test for "mapping" being NULL, and do the
NR_FILE_DIRY accounting purely based on mapping_cap_account_dirty()).
Also, add it to the exports, so that modular filesystems can use it.
Acked-by: Andrew Morton <akpm@xxxxxxxx>
Signed-off-by: Linus Torvalds <torvalds@xxxxxxxx>
---
mm/truncate.c | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/mm/truncate.c b/mm/truncate.c
index 4a38dd1..ecdfdcc 100644
--- a/mm/truncate.c
+++ b/mm/truncate.c
@@ -60,12 +60,16 @@ void cancel_dirty_page(struct page *page, unsigned int
account_size)
WARN_ON(++warncount < 5);
}
- if (TestClearPageDirty(page) && account_size &&
- mapping_cap_account_dirty(page->mapping)) {
- dec_zone_page_state(page, NR_FILE_DIRTY);
- task_io_account_cancelled_write(account_size);
+ if (TestClearPageDirty(page)) {
+ struct address_space *mapping = page->mapping;
+ if (mapping && mapping_cap_account_dirty(mapping)) {
+ dec_zone_page_state(page, NR_FILE_DIRTY);
+ if (account_size)
+ task_io_account_cancelled_write(account_size);
+ }
}
}
+EXPORT_SYMBOL(cancel_dirty_page);
/*
* If truncate cannot remove the fs-private metadata from the page, the page
commit ffaa82008f1aad52a6d3979f49d2a76c2928b60f
Author: Linus Torvalds <torvalds@xxxxxxxxxxxxxx>
Date: Sat Dec 23 09:32:45 2006 -0800
Fix reiserfs after "test_clear_page_dirty()" removal
Thanks to Len Brown for testing this fix, since while they have in the
past, none of my machines run reiserfs at the moment.
Cc: Vladimir V. Saveliev <vs@xxxxxxxxxxx>
Acked-by: Len Brown <lenb@xxxxxxxxxx>
Signed-off-by: Linus Torvalds <torvalds@xxxxxxxx>
---
fs/reiserfs/stree.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/reiserfs/stree.c b/fs/reiserfs/stree.c
index 47e7027..afb21ea 100644
--- a/fs/reiserfs/stree.c
+++ b/fs/reiserfs/stree.c
@@ -1459,7 +1459,7 @@ static void unmap_buffers(struct page *page, loff_t pos)
bh = next;
} while (bh != head);
if (PAGE_SIZE == bh->b_size) {
- clear_page_dirty(page);
+ cancel_dirty_page(page, PAGE_CACHE_SIZE);
}
}
}
Date: December 23, 2006
From: Randy Dunlap <randy.dunlap@xxxxxxxxxx>
In-reply-to:
<Pine.LNX.4.64.0612231004270.3671@xxxxxxxxxxxxxx>
References:
<458BEB9D.8030709@xxxxxxxx> <20061222223034.b29aeb5f.khali@xxxxxxxxxxxx> <Pine.LNX.4.64.0612221615430.3671@xxxxxxxxxxxxxx> <Pine.LNX.4.64.0612231004270.3671@xxxxxxxxxxxxxx>
On Sat, 23 Dec 2006 10:30:40 -0800 (PST) Linus Torvalds wrote: > > [ Andrew - I'm cc'ing you, because you caused the requirement that people > use "set_page_writeback()" in their writepage() routine that CIFS seems > to have been ignoring all these years. That was introduced more than > two years ago, back in April 11, 2004: > > [PATCH] fdatasync integrity fix > > fdatasync can fail to wait on some pages due to a race. > ... > > and as far as I can see, ever since then, any filesystem that didn't do > a "set_page_writeback()" to sync up the TAG_DIRTY bit would have this > CPU usage problem. Please double-check whether I'm right or barking up > the wrong tree. > > Afaik, the lack of doing the page writeback bit handling properly would > seem to not cause any actual visible _semantic_ problems, it would just > cause fdatasync to not necessarily be entirely reliable (which I guess > is semantic, but very hard to see) and just wasted CPU cycles when we > look up pages that are marked dirty in the radix tree, but aren't > actually really dirty. > > Correct? Who else is implicated in all of this? ] > > On Fri, 22 Dec 2006, Linus Torvalds wrote: > > > > CIFS _should_ be using "clear_page_dirty_for_io()" in that place, and that > > will fix the build. However, the reason I didn't just do that myself is > > that I can't test the end result, and for the life of me, I can't see > > where CIFS does the "end_page_writeback()" that it needs to do at IO > > completion time. > > Ok, I spent some more time looking at this. > > The reason cifs didn't do an "end_page_writeback()" was that it didn't > even do the "set_page_writeback()" to mark the page under writeback in the > first place. > > Now, you might think that since it didn't do a set_page_writeback(), it > doesn't need to do the matching end_page_writeback() at all, and instead > just continue to use the old (_really_ old) way of just unlocking the page > when it is done. > > However, you'd be wrong. The thing is, a "writepage()" function will be > called with the dirty bit cleared in the "struct page *", but the mapping > radix trees will still have the dirty bit set, exactly because the VM > _requires_ the filesystem to tell it what the h*ll it is doing with the > page. So a low-level filesystem must always do one of two things in it's > "writepage()" function. Either: > > - "set_page_writeback()" (and then an "end_page_writeback()" when > finished, of course) > > OR > > - "redirty_page_for_writepage()" to tell the VM to move the page to the > back of the LRU queues because it can't be cleaned (eg, some temporary > problem with write ordering or similar, or something fundamental like > "I'm ramfs, and I don't _have_ any backing store"). > > and if the low-level filesystem doesn't do either of those, then the > status bits in the radix tree that contains the mapping information will > never be updated, so the page that got cleaned will continue to be marked > "dirty" in the radix tree (which admittedly will generally be invisible, > except for "sync()" and friends spending inordinate amounts of time > looking at pages that aren't even dirty any more - since they look things > up by the radix tree tags). > > So I think the old code happened to work, but it was definitely incorrect, > and would leave the dirty tags in the radix tree very confused indeed (it > so happened that "cifs_writepages()" - with an "s" at the end - because it > used "test_clear_page_dirty()" - would also clear the dirty tag, but any > page that went through the generic VM routines and the single-page > "cifs_writepage()" - without an "s" at the end - would then be forever > marked dirty in the radix tree even though it was clean. > > Somebody should check me, though. > > This fairly mindless patch adds the proper "set_page_writeback()" calls > (and the "clear_page_writeback()" ones I had already added before I looked > more closely at this). > > I added a comment in "cifs_writepage()" (the single-page case) for why > this all is the case, BTW, reiserfs has similar build problems: it uses clear_page_dirty() so it won't build. fs/built-in.o: In function `reiserfs_cut_from_item': (.text.reiserfs_cut_from_item+0x868): undefined reference to `clear_page_dirty' --- ~Randy
Date: December 23, 2006
From: Steve French <smfltc@xxxxxxxxxx>
In-reply-to:
<458D7D15.8030609@xxxxxxxxxx>
References:
<20061223120042.BF064162AD9@xxxxxxxxxxxxxxx> <458D7D15.8030609@xxxxxxxxxx>
You are right that cifs didn't call end_page_writeback(page) - wonder if this was the cause of a rare corruption seen in writepages of very large files to Windows servers which was difficult to track down. Steve French wrote:
On Sat, 23 Dec 2006, Ian McDonald wrote:Well I can compile it OK and link now so that's better.No, as far as I'm concerned, compiling and linking is actually _worse_ ifthe end result then causes horrible problems. Which is why I'll leave it in the non-compiling stage in the standard kernel until I actually get somebody reporting whether the end result actually works or not (or an ACK from a CIFS person).I don't know really how to test but I'll tell you if CIFS interferes with my daschund.Remember to send pictures. LinusI am looking at the patch now, and it makes sense - but may also want to run it by Shaggy who probably wrote this section ofcifs_writepages originally.
Can anyone
Date: December 23, 2006
From: Steve French <smfltc@xxxxxxxxxx>
In-reply-to:
<20061223120042.BF064162AD9@xxxxxxxxxxxxxxx>
References:
<20061223120042.BF064162AD9@xxxxxxxxxxxxxxx>
On Sat, 23 Dec 2006, Ian McDonald wrote:Well I can compile it OK and link now so that's better.No, as far as I'm concerned, compiling and linking is actually _worse_ if the end result then causes horrible problems. Which is why I'll leave it in the non-compiling stage in the standard kernel until I actually get somebody reporting whether the end result actually works or not (or an ACK from a CIFS person).I don't know really how to test but I'll tell you if CIFS interferes with my daschund.Remember to send pictures. Linus
I am looking at the patch now, and it makes sense - but may also want to run it by Shaggy who probably wrote this section of
cifs_writepages originally.
Date: December 23, 2006
From: Linus Torvalds <torvalds@xxxxxxxx>
In-reply-to:
<Pine.LNX.4.64.0612221615430.3671@xxxxxxxxxxxxxx>
References:
<458BEB9D.8030709@xxxxxxxx> <20061222223034.b29aeb5f.khali@xxxxxxxxxxxx> <Pine.LNX.4.64.0612221615430.3671@xxxxxxxxxxxxxx>
[ Andrew - I'm cc'ing you, because you caused the requirement that people
use "set_page_writeback()" in their writepage() routine that CIFS seems
to have been ignoring all these years. That was introduced more than
two years ago, back in April 11, 2004:
[PATCH] fdatasync integrity fix
fdatasync can fail to wait on some pages due to a race.
...
and as far as I can see, ever since then, any filesystem that didn't do
a "set_page_writeback()" to sync up the TAG_DIRTY bit would have this
CPU usage problem. Please double-check whether I'm right or barking up
the wrong tree.
Afaik, the lack of doing the page writeback bit handling properly would
seem to not cause any actual visible _semantic_ problems, it would just
cause fdatasync to not necessarily be entirely reliable (which I guess
is semantic, but very hard to see) and just wasted CPU cycles when we
look up pages that are marked dirty in the radix tree, but aren't
actually really dirty.
Correct? Who else is implicated in all of this? ]
On Fri, 22 Dec 2006, Linus Torvalds wrote:
>
> CIFS _should_ be using "clear_page_dirty_for_io()" in that place, and that
> will fix the build. However, the reason I didn't just do that myself is
> that I can't test the end result, and for the life of me, I can't see
> where CIFS does the "end_page_writeback()" that it needs to do at IO
> completion time.
Ok, I spent some more time looking at this.
The reason cifs didn't do an "end_page_writeback()" was that it didn't
even do the "set_page_writeback()" to mark the page under writeback in the
first place.
Now, you might think that since it didn't do a set_page_writeback(), it
doesn't need to do the matching end_page_writeback() at all, and instead
just continue to use the old (_really_ old) way of just unlocking the page
when it is done.
However, you'd be wrong. The thing is, a "writepage()" function will be
called with the dirty bit cleared in the "struct page *", but the mapping
radix trees will still have the dirty bit set, exactly because the VM
_requires_ the filesystem to tell it what the h*ll it is doing with the
page. So a low-level filesystem must always do one of two things in it's
"writepage()" function. Either:
- "set_page_writeback()" (and then an "end_page_writeback()" when
finished, of course)
OR
- "redirty_page_for_writepage()" to tell the VM to move the page to the
back of the LRU queues because it can't be cleaned (eg, some temporary
problem with write ordering or similar, or something fundamental like
"I'm ramfs, and I don't _have_ any backing store").
and if the low-level filesystem doesn't do either of those, then the
status bits in the radix tree that contains the mapping information will
never be updated, so the page that got cleaned will continue to be marked
"dirty" in the radix tree (which admittedly will generally be invisible,
except for "sync()" and friends spending inordinate amounts of time
looking at pages that aren't even dirty any more - since they look things
up by the radix tree tags).
So I think the old code happened to work, but it was definitely incorrect,
and would leave the dirty tags in the radix tree very confused indeed (it
so happened that "cifs_writepages()" - with an "s" at the end - because it
used "test_clear_page_dirty()" - would also clear the dirty tag, but any
page that went through the generic VM routines and the single-page
"cifs_writepage()" - without an "s" at the end - would then be forever
marked dirty in the radix tree even though it was clean.
Somebody should check me, though.
This fairly mindless patch adds the proper "set_page_writeback()" calls
(and the "clear_page_writeback()" ones I had already added before I looked
more closely at this).
I added a comment in "cifs_writepage()" (the single-page case) for why
this all is the case,
Linus
PS. To clarify: the old "test_clear_page_dirty()" would actually clear the
dirty bit in the radix tree too, so in that sense it was the RIGHT thing
to do for CIFS, since CIFS was mostly unaware of the need to clear the
radix tree dirty bit (even if cifs_writepages() actually used that bit to
look up pages).
HOWEVER, since CIFS is called from the generic routines (which _are_
radix-tree-aware and need the bit to be cleared explicitly), even the old
code was actually totally broken. It would clear - largely by mistake -
the radix tree dirty bit only for one case, not for _all_ the cases. A
filesystem really does need to know about these things now, although a
lot of filesystems can ignore them, since if they use all the generic
routines, they generic routines will handle it all for them.
---
diff --git a/fs/cifs/file.c b/fs/cifs/file.c
index 0f05cab..8a49b2e 100644
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -1245,14 +1245,21 @@ retry:
wait_on_page_writeback(page);
if (PageWriteback(page) ||
- !test_clear_page_dirty(page)) {
+ !clear_page_dirty_for_io(page)) {
unlock_page(page);
break;
}
+ /*
+ * This actually clears the dirty bit in the radix tree.
+ * See cifs_writepage() for more commentary.
+ */
+ set_page_writeback(page);
+
if (page_offset(page) >= mapping->host->i_size) {
done = 1;
unlock_page(page);
+ end_page_writeback(page);
break;
}
@@ -1316,6 +1323,7 @@ retry:
SetPageError(page);
kunmap(page);
unlock_page(page);
+ end_page_writeback(page);
page_cache_release(page);
}
if ((wbc->nr_to_write -= n_iov) <= 0)
@@ -1352,11 +1360,23 @@ static int cifs_writepage(struct page* page, struct
writeback_control *wbc)
if (!PageUptodate(page)) {
cFYI(1, ("ppw - page not up to date"));
}
-
+
+ /*
+ * Set the "writeback" flag, and clear "dirty" in the radix tree.
+ *
+ * A writepage() implementation always needs to do either this,
+ * or re-dirty the page with "redirty_page_for_writepage()" in
+ * the case of a failure.
+ *
+ * Just unlocking the page will cause the radix tree tag-bits
+ * to fail to update with the state of the page correctly.
+ */
+ set_page_writeback(page);
rc = cifs_partialpagewrite(page, 0, PAGE_CACHE_SIZE);
SetPageUptodate(page); /* BB add check for error and Clearuptodate? */
unlock_page(page);
- page_cache_release(page);
+ end_page_writeback(page);
+ page_cache_release(page);
FreeXid(xid);
return rc;
}
Date: December 23, 2006
From: Linus Torvalds <torvalds@xxxxxxxx>
In-reply-to:
<5640c7e00612221747g24f8d4caxa9ee884989edce1a@xxxxxxxxxxxxxx>
References:
<5640c7e00612221721h1463aad2xf01c2785c6febce0@xxxxxxxxxxxxxx> <Pine.LNX.4.64.0612221727420.3671@xxxxxxxxxxxxxx> <5640c7e00612221747g24f8d4caxa9ee884989edce1a@xxxxxxxxxxxxxx>
On Sat, 23 Dec 2006, Ian McDonald wrote:
>
> Well I can compile it OK and link now so that's better.
No, as far as I'm concerned, compiling and linking is actually _worse_ if
the end result then causes horrible problems.
Which is why I'll leave it in the non-compiling stage in the standard
kernel until I actually get somebody reporting whether the end result
actually works or not (or an ACK from a CIFS person).
> I don't know really how to test but I'll tell you if CIFS interferes
> with my daschund.
Remember to send pictures.
Linus
Date: December 23, 2006
From: "Ian McDonald" <ian.mcdonald@xxxxxxxxxxx>
In-reply-to:
<Pine.LNX.4.64.0612221727420.3671@xxxxxxxxxxxxxx>
References:
<5640c7e00612221721h1463aad2xf01c2785c6febce0@xxxxxxxxxxxxxx> <Pine.LNX.4.64.0612221727420.3671@xxxxxxxxxxxxxx>
On 12/23/06, Linus Torvalds <torvalds@xxxxxxxx> wrote:
On Sat, 23 Dec 2006, Ian McDonald wrote:
>
> This isn't my area of expertise so I'm not providing a fix as I'm sure
> I'll get it wrong!
Well, I probably get it wrong too, but here's an email I already sent out
to some people who could at least _test_ it (which I can't).
The more people who see this and can test it, the better..
Linus
---
Well I can compile it OK and link now so that's better. I don't know really how to test but I'll tell you if CIFS interferes with my daschund. Regards, Ian -- Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group
Date: December 23, 2006
From: Randy Dunlap <randy.dunlap@xxxxxxxxxx>
In-reply-to:
<5640c7e00612221721h1463aad2xf01c2785c6febce0@xxxxxxxxxxxxxx>
References:
<5640c7e00612221721h1463aad2xf01c2785c6febce0@xxxxxxxxxxxxxx>
On Sat, 23 Dec 2006 14:21:48 +1300 Ian McDonald wrote:
> In commit fba2591bf4e418b6c3f9f8794c9dd8fe40ae7bd9
> test_clear_page_dirty was removed a couple of days ago.
>
> Now when I try and build I get this:
> WARNING: "test_clear_page_dirty" [fs/cifs/cifs.ko] undefined!
>
> This is caused by line 1248 of fs/cifs/file.c
> if (PageWriteback(page) ||
> !test_clear_page_dirty(page)) {
>
> This isn't my area of expertise so I'm not providing a fix as I'm sure
> I'll get it wrong!
>
> My apologies if people have already fixed as I'm not on all the relevant
> lists.
Linus posted an (untested) patch for this about 10 minutes ago.
Is this something that you can test? (see below)
---
On Fri, 22 Dec 2006, Jean Delvare wrote:
>
> The approach seems quite broken to me, the users should have been fixed
> _before_ removing the function, so as to avoid compilation failures.
> These are a pain for testers, and break git bisect too. Grmbl.
This needed to be fixed, and quite frankly, things don't get fixed nearly
as quickly if you don't just break them first. And there really were just
two filesystems that got broken, cifs being one of them.
I just can't test it.
> Now that it's done... Steve, can you please take a look and provide a
> patch so that cifs builds again?
CIFS _should_ be using "clear_page_dirty_for_io()" in that place, and that
will fix the build. However, the reason I didn't just do that myself is
that I can't test the end result, and for the life of me, I can't see
where CIFS does the "end_page_writeback()" that it needs to do at IO
completion time.
And the thing that confuses me about that, is that if CIFS doesn't do
"end_page_writeback()", then it was already broken before - because when
the VM calls "->writepage()" the clear_page_dirty_for_io() will have been
done by the VM, and it needs that "end_page_writeback()" so that the
system can know when the IO is done.
I _suspect_ that those "unlock_page()" calls should be accompanied by a
"end_page_writeback()" call, and that the proper patch MAY look something
like the appended, but I worry about having missed something really
subtle. Maybe there's a end_page_writeback() somewhere else.
And if there isn't, I wonder if shared mappings have _ever_ worked on
CIFS? And if so, how? That writeback bit thing isn't new per se.
So this may or may not fix it. If you can test it (_including_ with some
dirty shared mmap-on-mmap action, please - just call me kinky), I'll
commit it. But I need somebody who actually uses this to test it.
Linus
---
diff --git a/fs/cifs/file.c b/fs/cifs/file.c
index 0f05cab..4f0472d 100644
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -1245,7 +1245,7 @@ retry:
wait_on_page_writeback(page);
if (PageWriteback(page) ||
- !test_clear_page_dirty(page)) {
+ !clear_page_dirty_for_io(page)) {
unlock_page(page);
break;
}
@@ -1253,6 +1253,7 @@ retry:
if (page_offset(page) >= mapping->host->i_size) {
done = 1;
unlock_page(page);
+ end_page_writeback(page);
break;
}
@@ -1316,6 +1317,7 @@ retry:
SetPageError(page);
kunmap(page);
unlock_page(page);
+ end_page_writeback(page);
page_cache_release(page);
}
if ((wbc->nr_to_write -= n_iov) <= 0)
@@ -1356,7 +1358,8 @@ static int cifs_writepage(struct page* page, struct
writeback_control *wbc)
rc = cifs_partialpagewrite(page, 0, PAGE_CACHE_SIZE);
SetPageUptodate(page); /* BB add check for error and Clearuptodate? */
unlock_page(page);
- page_cache_release(page);
+ end_page_writeback(page);
+ page_cache_release(page);
FreeXid(xid);
return rc;
}
-
Date: December 23, 2006
From: Linus Torvalds <torvalds@xxxxxxxx>
In-reply-to:
<5640c7e00612221721h1463aad2xf01c2785c6febce0@xxxxxxxxxxxxxx>
References:
<5640c7e00612221721h1463aad2xf01c2785c6febce0@xxxxxxxxxxxxxx>
On Sat, 23 Dec 2006, Ian McDonald wrote:
>
> This isn't my area of expertise so I'm not providing a fix as I'm sure
> I'll get it wrong!
Well, I probably get it wrong too, but here's an email I already sent out
to some people who could at least _test_ it (which I can't).
The more people who see this and can test it, the better..
Linus
---
Date: Fri, 22 Dec 2006 16:25:42 -0800 (PST)
From: Linus Torvalds <torvalds@xxxxxxxx>
To: Jean Delvare <khali@xxxxxxxxxxxx>
cc: Thomas Meyer <thomas@xxxxxxxx>, Steve French <sfrench@xxxxxxxxx>,
linux-kernel@xxxxxxxxxxxxxxx
Subject: Re: WARNING: "test_clear_page_dirty" [fs/cifs/cifs.ko] undefined!
Message-ID: <Pine.LNX.4.64.0612221615430.3671@xxxxxxxxxxxxxx>
On Fri, 22 Dec 2006, Jean Delvare wrote:
>
> The approach seems quite broken to me, the users should have been fixed
> _before_ removing the function, so as to avoid compilation failures.
> These are a pain for testers, and break git bisect too. Grmbl.
This needed to be fixed, and quite frankly, things don't get fixed nearly
as quickly if you don't just break them first. And there really were just
two filesystems that got broken, cifs being one of them.
I just can't test it.
> Now that it's done... Steve, can you please take a look and provide a
> patch so that cifs builds again?
CIFS _should_ be using "clear_page_dirty_for_io()" in that place, and that
will fix the build. However, the reason I didn't just do that myself is
that I can't test the end result, and for the life of me, I can't see
where CIFS does the "end_page_writeback()" that it needs to do at IO
completion time.
And the thing that confuses me about that, is that if CIFS doesn't do
"end_page_writeback()", then it was already broken before - because when
the VM calls "->writepage()" the clear_page_dirty_for_io() will have been
done by the VM, and it needs that "end_page_writeback()" so that the
system can know when the IO is done.
I _suspect_ that those "unlock_page()" calls should be accompanied by a
"end_page_writeback()" call, and that the proper patch MAY look something
like the appended, but I worry about having missed something really
subtle. Maybe there's a end_page_writeback() somewhere else.
And if there isn't, I wonder if shared mappings have _ever_ worked on
CIFS? And if so, how? That writeback bit thing isn't new per se.
So this may or may not fix it. If you can test it (_including_ with some
dirty shared mmap-on-mmap action, please - just call me kinky), I'll
commit it. But I need somebody who actually uses this to test it.
Linus
---
diff --git a/fs/cifs/file.c b/fs/cifs/file.c
index 0f05cab..4f0472d 100644
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -1245,7 +1245,7 @@ retry:
wait_on_page_writeback(page);
if (PageWriteback(page) ||
- !test_clear_page_dirty(page)) {
+ !clear_page_dirty_for_io(page)) {
unlock_page(page);
break;
}
@@ -1253,6 +1253,7 @@ retry:
if (page_offset(page) >= mapping->host->i_size) {
done = 1;
unlock_page(page);
+ end_page_writeback(page);
break;
}
@@ -1316,6 +1317,7 @@ retry:
SetPageError(page);
kunmap(page);
unlock_page(page);
+ end_page_writeback(page);
page_cache_release(page);
}
if ((wbc->nr_to_write -= n_iov) <= 0)
@@ -1356,7 +1358,8 @@ static int cifs_writepage(struct page* page, struct
writeback_control *wbc)
rc = cifs_partialpagewrite(page, 0, PAGE_CACHE_SIZE);
SetPageUptodate(page); /* BB add check for error and Clearuptodate? */
unlock_page(page);
- page_cache_release(page);
+ end_page_writeback(page);
+ page_cache_release(page);
FreeXid(xid);
return rc;
}
Date: December 23, 2006
From: "Ian McDonald" <ian.mcdonald@xxxxxxxxxxx>
In commit fba2591bf4e418b6c3f9f8794c9dd8fe40ae7bd9
test_clear_page_dirty was removed a couple of days ago.
Now when I try and build I get this:
WARNING: "test_clear_page_dirty" [fs/cifs/cifs.ko] undefined!
This is caused by line 1248 of fs/cifs/file.c
if (PageWriteback(page) ||
!test_clear_page_dirty(page)) {
This isn't my area of expertise so I'm not providing a fix as I'm sure
I'll get it wrong!
My apologies if people have already fixed as I'm not on all the relevant lists.
Regards,
Ian
--
Web: http://wand.net.nz/~iam4
Blog: http://imcdnzl.blogspot.com
WAND Network Research Group
Date: December 20, 2006
From: "Mark Buechler" <mark.buechler@xxxxxxxxx>
In-reply-to:
<20061218221255.GA4209@linux
>
References:
<3e9048940612181224g1e93aba6ob5ef1a6478ff6ab2@xxxxxxxxxxxxxx> <20061218221255.GA4209@linux
>
On Mon, Dec 18, 2006 at 03:24:28PM -0500, Mark Buechler wrote:
> I'm running samba v3.0.23c and the latest cifs kernel module on my cifs
> client. I'm mounting my samba share on my client with "-o direct". I'm
> seeing something odd with regard to unlinking open files. I run MythTV. When
> Myth deletes a recording, rather than doing a straight unlink it does the
> following:
>
> 1. Open file
> 2. Gradually truncate the file
> 3. When the file gets below a certain file size, unlink it
> 4. Close file
>
> This behavior has a side effect of leaving the truncated files hanging
> around but renamed as cifs??? files. Ie:
Hmmm. Steve - how about using the CIFS UNIX call SMB_SET_FILE_UNIX_BASIC
(trans2 call info level 0x200) with a st_nlink count of zero and a
file type of UNIX_TYPE_FILE (0) to unlink a file ? That way would
work for open files without having to invent a new UNIX_unlink
call ? Currently st_nlink of zero is used in a "special" way
to do mknod calls so there is precedence for this ?
What do you think ?
Jeremy.
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: December 19, 2006
From: Chuck Ebbert <76306.1226@xxxxxxxxxxxxxx>
In-Reply-To: <1166458956.30152.18.camel@xxxxxxxxxxxxxxxxxxxxx> On Mon, 18 Dec 2006 11:22:36 -0500, simo wrote: > > With cifs, a directory search shows different sizes but opening > > them by name gives identical contents: > > > > $ ll ipt_dscp* ipt_DSCP* > > -r-------- 1 me me 1581 Jan 28 2004 ipt_dscp.c > > -r-------- 1 me me 2753 Jan 29 2004 ipt_DSCP.c > > $ ll ipt_dscp.c ipt_DSCP.c > > -r-------- 1 me me 1581 Jan 28 2004 ipt_dscp.c > > -r-------- 1 me me 1581 Jan 28 2004 ipt_DSCP.c > > $ diff ipt_dscp.c ipt_DSCP.c > > $ > > > > So where is the bug? On the server? > > What is the server? > Samba? Which vertsion? Samba 2.2.3. > Do you use unix extensions? Or "case sensitive = yes" ? No UNIX extensions. Not case sensitive. SO this is kind of expected, but smbfs and cifs client for Linux have subtly different behavior. -- MBTI: IXTP
Date: December 19, 2006
From: "Christopher R. Hertel" <crh@xxxxxxxxxxxx>
In-reply-to:
<4582F63B.6080604@xxxxxxxxxx>
References:
<4582C2D4.4010805@xxxxxxxxxx> <4582E339.7030006@xxxxxxxxxxxx> <4582F63B.6080604@xxxxxxxxxx>
Sorry for the delay replying... Steve French wrote: : > I probably need to make this a mount parm, but currently users do > echo 0 > /proc/fs/cifs/LinuxExtensionsEnabled > mount -t cifs //server/share /mnt ... > echo 1 > /proc/fs/cifs/LinuxExtensionsEnabled Ah. That'll do it for now. Yes, it'd be nice if that were a parameter. > Could you explain what you want in more detail? > > uid/gid/mode support works if the server supports the Unix extensions - > mode bits are evaluated on > the client (generic_permission in the vfs) - what user you choose to use > to mount on the server > does not really matter for the client access decision as long as you > have access on the server > for that share for that id specified on mount (or if you don't want to > send a username > you can try "sec=none" to send a null user and "guest" so it does not > prompt for password) I think that this is where I have had problems. Perhaps my copy of the software is too old (I'm using stock SuSE right now). When I get a guest connection I don't seem to get the right permissions. Here's the setup: [global] workgroup = ubiqx username map = /etc/samba/smbusers map to guest = Bad User guest account = nobody time server = yes unix extensions = yes map archive = no security = user [test] path = /tmp browseable = no writable = yes guest ok = yes So, I # mount -t cifs -o sec=none,guest //hulk/test /mnt # touch /mnt/foo.root and then from a non-superuser account I $ touch /mnt/foo.user touch: setting times of `/mnt/foo.user': Permission denied Interesting, so... $ ls -l /mnt/foo.* -rw-r--r-- 1 nobody nobody 0 2006-12-18 21:26 /mnt/foo.root -rw-r--r-- 1 nobody nobody 0 2006-12-18 21:27 /mnt/foo.user Both of the files (one created by root, one by crh.users) are owned by nobody.nobody. Hmmm.... Other files (created on the server side) show the correct owner and group, so I know that the extensions are working to some degree. My guess is that I'm dealing with out-of-date software on my end. The CHANGES file on the client side says I've got CIFS VFS v 1.40. The server says it's Version 3.0.13-1.3-SUSE. Send along any clues. Thanks! Chris -)----- -- "Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X Samba Team -- http://www.samba.org/ -)----- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)----- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)----- crh@xxxxxxxxxxxx OnLineBook -- http://ubiqx.org/cifs/ -)----- crh@xxxxxxxxx
Date: December 18, 2006
From: Jeremy Allison <jra@xxxxxxxxx>
In-reply-to:
<3e9048940612181224g1e93aba6ob5ef1a6478ff6ab2@xxxxxxxxxxxxxx>
References:
<3e9048940612181224g1e93aba6ob5ef1a6478ff6ab2@xxxxxxxxxxxxxx>
On Mon, Dec 18, 2006 at 03:24:28PM -0500, Mark Buechler wrote: > I'm running samba v3.0.23c and the latest cifs kernel module on my cifs > client. I'm mounting my samba share on my client with "-o direct". I'm > seeing something odd with regard to unlinking open files. I run MythTV. When > Myth deletes a recording, rather than doing a straight unlink it does the > following: > > 1. Open file > 2. Gradually truncate the file > 3. When the file gets below a certain file size, unlink it > 4. Close file > > This behavior has a side effect of leaving the truncated files hanging > around but renamed as cifs??? files. Ie: Hmmm. Steve - how about using the CIFS UNIX call SMB_SET_FILE_UNIX_BASIC (trans2 call info level 0x200) with a st_nlink count of zero and a file type of UNIX_TYPE_FILE (0) to unlink a file ? That way would work for open files without having to invent a new UNIX_unlink call ? Currently st_nlink of zero is used in a "special" way to do mknod calls so there is precedence for this ? What do you think ? Jeremy.
Date: December 18, 2006
From: simo <idra@xxxxxxxxx>
In-reply-to:
<200612181115_MC3-1-D578-937D@xxxxxxxxxxxxxx>
References:
<200612181115_MC3-1-D578-937D@xxxxxxxxxxxxxx>
On Mon, 2006-12-18 at 11:13 -0500, Chuck Ebbert wrote: > With cifs, a directory search shows different sizes but opening > them by name gives identical contents: > > $ ll ipt_dscp* ipt_DSCP* > -r-------- 1 me me 1581 Jan 28 2004 ipt_dscp.c > -r-------- 1 me me 2753 Jan 29 2004 ipt_DSCP.c > $ ll ipt_dscp.c ipt_DSCP.c > -r-------- 1 me me 1581 Jan 28 2004 ipt_dscp.c > -r-------- 1 me me 1581 Jan 28 2004 ipt_DSCP.c > $ diff ipt_dscp.c ipt_DSCP.c > $ > > So where is the bug? On the server? What is the server? Samba? Which vertsion? Do you use unix extensions? Or "case sensitive = yes" ? Simo. -- Simo Sorce Samba Team GPL Compliance Officer email: idra@xxxxxxxxx http://samba.org
Date: December 18, 2006
From: Chuck Ebbert <76306.1226@xxxxxxxxxxxxxx>
In-Reply-To: <4586408C.2050408@xxxxxxxxxx> On Mon, 18 Dec 2006 09:17:32 +0200, Ava Kivity wrote: > In 2.6.20-rc1, some of these files have other files with the same name > in the same directory (modulo case). Perhaps this is confusing cifs. > > Can you check where all of the files in your case share that property? > > example: > > [avi@firebolt linux-2.6]$ find net -iname ipt_tos.c > net/ipv4/netfilter/ipt_TOS.c > net/ipv4/netfilter/ipt_tos.c > > [avi@firebolt linux-2.6]$ find net -iname ipt_ecn.c > net/ipv4/netfilter/ipt_ECN.c > net/ipv4/netfilter/ipt_ecn.c Yes, that's it. Using smbfs, both files have the same size and contents even though they're really different: $ ll ipt_dscp* ipt_DSCP* -r--r----- 1 me me 2753 Jan 29 2004 ipt_dscp.c -r--r----- 1 me me 2753 Jan 29 2004 ipt_DSCP.c $ ll ipt_dscp.c ipt_DSCP.c -r--r----- 1 me me 2753 Jan 29 2004 ipt_dscp.c -r--r----- 1 me me 2753 Jan 29 2004 ipt_DSCP.c With cifs, a directory search shows different sizes but opening them by name gives identical contents: $ ll ipt_dscp* ipt_DSCP* -r-------- 1 me me 1581 Jan 28 2004 ipt_dscp.c -r-------- 1 me me 2753 Jan 29 2004 ipt_DSCP.c $ ll ipt_dscp.c ipt_DSCP.c -r-------- 1 me me 1581 Jan 28 2004 ipt_dscp.c -r-------- 1 me me 1581 Jan 28 2004 ipt_DSCP.c $ diff ipt_dscp.c ipt_DSCP.c $ So where is the bug? On the server? -- MBTI: IXTP
Date: December 18, 2006
From: "Shanti kishore Balusu" <kishorechowdary@xxxxxxxxx>
I am facing a problem using cifs filesytem on centos 4.3 32 bit to connect to remote shares.we have DAS(Dell md1000) connected to a Dell 2950(win 2003 std edition).let me descibe the proc which i followed to access this DAS via 2950.. 1) create a normal user account on Dell2950(win 2003) create 3 folders with names mysqhare1,myshare2,myshare3 in the storage area and assign all permissions to the newly created user(duser).right click newly created folder share them remove all accounts execpt admin & newly created user & assign full permissions to that share to newly created user(duser) 2) proc used to access shares via cifs wget http://pserver.samba.org/samba/ftp/cifs-cvs/mount.cifs mv mount.cifs /sbin/mount.cifs chmod +x /sbin/mount.cifs mount.cifs //MYDAS/Myshare1 /var/www/html/Myshare1 -o username=duser,password=mydpass,rw mount.cifs //MYDAS/Myshare2 /var/www/html/Myshare2 -o username=duser,password=mydpass,rw mount.cifs //MYDAS/Myshare3 /var/www/html/Myshare3 -o username=duser,password=mydpass,rw Note: MYDAS is pointed to the correct IP in /etc/hosts service httpd stop service httpd start We server flv files from these shares ie a kind of progressive download server(flv streaming using phpflv player) when i start serving files i keep getting the below errors in my dmesg & /var/log/messages.after a few hours of serving server totally hangs(not accessible via ssh) & has to be hard rebooted manully CIFS VFS: Send error in Close = -9 CIFS VFS: Send error in Close = -9 CIFS VFS: Send error in Close = -9 CIFS VFS: Send error in Close = -9 CIFS VFS: Send error in Close = -9 CIFS VFS: Send error in Close = -9 CIFS VFS: Send error in Close = -9 CIFS VFS: Send error in Close = -9 CIFS VFS: Send error in Close = -9 CIFS VFS: Send error in Close = -9 CIFS VFS: Send error in Close = -9 CIFS VFS: Send error in Close = -9 CIFS VFS: Send error in Close = -9 CIFS VFS: Send error in Close = -9 CIFS VFS: Send error in Close = -9 CIFS VFS: Send error in Close = -9 CIFS VFS: Send error in Close = -9 CIFS VFS: Send error in Close = -9 CIFS VFS: Send error in Close = -9 CIFS VFS: Send error in Close = -9 CIFS VFS: Send error in Close = -9 TCP: Treason uncloaked! Peer 80.235.63.248:64721/37374 shrinks window 1814256320:1814257772. Repaired. TCP: Treason uncloaked! Peer 80.235.63.248:64721/37374 shrinks window 1814256320:1814257772. Repaired. TCP: Treason uncloaked! Peer 196.29.40.33:42283/80 shrinks window 1747071341:1747071342. Repaired. TCP: Treason uncloaked! Peer 196.29.40.33:42283/80 shrinks window 1747071341:1747071342. Repaired. TCP: Treason uncloaked! Peer 200.219.181.142:42319/80 shrinks window 2850231833:2850231834. Repaired. TCP: Treason uncloaked! Peer 80.72.16.157:25598/80 shrinks window 3404607524:3404607525. Repaired. TCP: Treason uncloaked! Peer 69.71.145.10:61695/80 shrinks window 588793866:588793867. Repaired. TCP: Treason uncloaked! Peer 69.71.145.10:61695/80 shrinks window 588793866:588793867. Repaired. TCP: Treason uncloaked! Peer 69.71.145.10:61427/80 shrinks window 1127016461:1127016462. Repaired. TCP: Treason uncloaked! Peer 69.71.145.10:61427/80 shrinks window 1127016461:1127016462. Repaired. TCP: Treason uncloaked! Peer 69.71.145.10:61427/80 shrinks window 1127016461:1127016462. Repaired. TCP: Treason uncloaked! Peer 69.71.145.10:64133/80 shrinks window 1285353070:1285353071. Repaired. TCP: Treason uncloaked! Peer 69.71.145.10:64133/80 shrinks window 1285353070:1285353071. Repaired. TCP: Treason uncloaked! Peer 69.71.145.10:61417/80 shrinks window 1339027766:1339027767. Repaired. TCP: Treason uncloaked! Peer 209.198.241.58:1588/80 shrinks window 1933324239:1933324240. Repaired. TCP: Treason uncloaked! Peer 209.198.241.58:1588/80 shrinks window 1933324239:1933324240. Repaired. TCP: Treason uncloaked! Peer 209.198.241.58:1624/80 shrinks window 1932659556:1932659557. Repaired. TCP: Treason uncloaked! Peer 209.198.241.58:1638/80 shrinks window 1940233619:1940233620. Repaired. TCP: Treason uncloaked! Peer 209.198.241.58:1674/80 shrinks window 1940660229:1940660230. Repaired. TCP: Treason uncloaked! Peer 209.198.241.58:1696/80 shrinks window 1958796647:1958796648. Repaired. TCP: Treason uncloaked! Peer 62.68.71.146:2892/80 shrinks window 2790037614:2790037615. Repaired. TCP: Treason uncloaked! Peer 62.68.71.146:2892/80 shrinks window 2790037614:2790037615. Repaired. TCP: Treason uncloaked! Peer 62.68.71.146:2892/80 shrinks window 2790037614:2790037615. Repaired. TCP: Treason uncloaked! Peer 203.81.202.13:58537/20 shrinks window 3133631691:3133633151. Repaired. TCP: Treason uncloaked! Peer 62.68.66.170:10684/80 shrinks window 3483220098:3483220099. Repaired. TCP: Treason uncloaked! Peer 62.68.66.170:10685/80 shrinks window 3482623769:3482623770. Repaired. TCP: Treason uncloaked! Peer 62.68.66.170:10684/80 shrinks window 3483220098:3483220099. Repaired. TCP: Treason uncloaked! Peer 62.68.66.170:10685/80 shrinks window 3482623769:3482623770. Repaired. TCP: Treason uncloaked! Peer 62.68.66.170:10684/80 shrinks window 3483220098:3483220099. Repaired. TCP: Treason uncloaked! Peer 62.68.66.170:10685/80 shrinks window 3482623769:3482623770. Repaired. TCP: Treason uncloaked! Peer 62.68.66.170:10735/80 shrinks window 3577903330:3577903331. Repaired. TCP: Treason uncloaked! Peer 62.68.66.170:10735/80 shrinks window 3577903330:3577903331. Repaired. TCP: Treason uncloaked! Peer 62.68.66.170:10740/80 shrinks window 3591049537:3591049538. Repaired. TCP: Treason uncloaked! Peer 62.68.66.170:10740/80 shrinks window 3591049537:3591049538. Repaired. TCP: Treason uncloaked! Peer 62.68.66.170:10746/80 shrinks window 3602348201:3602348202. Repaired. TCP: Treason uncloaked! Peer 62.68.66.170:10740/80 shrinks window 3591049537:3591049538. Repaired. TCP: Treason uncloaked! Peer 62.68.66.170:10746/80 shrinks window 3602348201:3602348202. Repaired. TCP: Treason uncloaked! Peer 62.192.136.18:61855/80 shrinks window 1829344868:1829344869. Repaired. TCP: Treason uncloaked! Peer 62.192.136.18:64129/80 shrinks window 1834509995:1834509996. Repaired. TCP: Treason uncloaked! Peer 62.192.136.18:64129/80 shrinks window 1834509995:1834509996. Repaired. please help me find a sollution for my above problem.. below are the hardware & os details.. Hardware Dell1850 with 4 gig mem OS: Centos 4.3 32 bit Thanx & Regards Kishore Chowdary
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: December 18, 2006
From: Hari Sekhon <hpsekhon@xxxxxxxxxxxxxx>
I am using cifs to mount windows 2003 server shares like this # mount -t cifs //hostname/d /mnt/temp/ -o username=mydomain/administrator Password: mount error 20 = Not a directory Refer to the mount.cifs(8) manual page (e.g.man mount.cifs) But it is a directory! # ll /mnt/ total 16 drwx------ 2 root root 4096 Aug 3 15:23 cdrom/ drwx------ 2 root root 4096 Aug 3 15:23 floppy/ drwxr-xr-x 2 root root 4096 Oct 18 12:53 temp/ drwxr-xr-x 2 root root 4096 Oct 17 10:24 usb/ I'm quite stuck on this. Is it a bug or what? If I try smbfs instead then I get the following: # mount -t smbfs //hostname/d /mnt/temp/ -o username=mydomain/administrator Password: 18751: session setup failed: ERRDOS - ERRnoaccess (Access denied.) SMB connection failedWhy am I getting error denied or these strange results when I know the password is correct, I use it all the time and I have tried it several times...
I'd much appreciate it if anybody could help out on this. I have the same problem from all my linux machines trying to connect to any Windows 2003 server in my new Active Directory 2003 domain. Windows 2000 servers connect fine, as do XP Sp2 workstations. I have this problem on all Windows 2003 servers that I can tell including domain controllers and member servers (non domain controllers).
I have tried making the group policies for the domain as follows:Domain member: Digitally encrypt or sign secure channel data (always) disabled Domain member: Digitally encrypt secure channel data (when possible) disabled Domain member: Digitally sign secure channel data (when possible) disabled
Microsoft network client: Digitally sign communications (always) disabled Microsoft network client: Digitally sign communications (if server agrees) disabled
Microsoft network server: Digitally sign communications (always) disabled Microsoft network server: Digitally sign communications (if client agrees) disabled
Domain Controller: LDAP server signing requirements none Network security: LDAP client signing requirements none
Network security: Lan Manager authentication level Send LM & NTLM responses
In the Windows logs I get Dec 18 14:18:50 hostname security[failure] 529 NT AUTHORITY\SYSTEM Logon Failure: Reason:Unknown user name or bad password User Name:ROOT Domain:MYDOMAIN Logon Type:3 Logon Process:NtLmSsp Authentication Package:NTLM Workstation Name:\\x.x.x.x Caller User Name:- Caller Domain:- Caller Logon ID:- Caller Process ID:- Transited Services:- Source Network Address:x.x.x.x Source Port:0 I don't understand why it says ROOT instead of administrator for username?The linux hosts are not members of the domain and have not been integrated to use kerberos or anything like that yet, but they do have the right username and password for the domain admin account.
So why doesn't this work? -h -- Hari Sekhon
Date: December 18, 2006
From: Avi Kivity <avi@xxxxxxxxxx>
In-reply-to:
<200612180106_MC3-1-D56B-FD2F@xxxxxxxxxxxxxx>
References:
<200612180106_MC3-1-D56B-FD2F@xxxxxxxxxxxxxx>
Chuck Ebbert wrote:
Trying to backup up a filesystem mounted via CIFS, I got these messages from tar: tar: t/2.6.10-orig/net/ipv4/netfilter/ipt_CONNMARK.c: File shrank by 1178 bytes; padding with zeros tar: t/2.6.10-orig/net/ipv4/netfilter/ipt_TCPMSS.c: File shrank by 4177 bytes; padding with zeros tar: t/2.6.10-orig/net/ipv4/netfilter/ipt_DSCP.c: File shrank by 1172 bytes; padding with zeros tar: t/2.6.10-orig/net/ipv4/netfilter/ipt_tos.c: file changed as we read it tar: t/2.6.10-orig/net/ipv4/netfilter/ipt_ECN.c: File shrank by 1638 bytes; padding with zeros tar: t/2.6.10-orig/net/ipv4/netfilter/ipt_mark.c: file changed as we read it tar: t/2.6.10-orig/net/ipv6/netfilter/ip6t_mark.c: file changed as we read it This was with kernel 2.6.19.1 SMP on x86_64, creating a tar file on a local jfs filesystem (t is the source path on a cifs mount.) Using 2.6.18.6-pre2 uniprocessor i386, with smbfs instead of cifs, everything works fine so I'm pretty sure the server is OK. Does this match any known problems?
In 2.6.20-rc1, some of these files have other files with the same name in the same directory (modulo case). Perhaps this is confusing cifs.
Can you check where all of the files in your case share that property? example: [avi@firebolt linux-2.6]$ find net -iname ipt_tos.c net/ipv4/netfilter/ipt_TOS.c net/ipv4/netfilter/ipt_tos.c [avi@firebolt linux-2.6]$ find net -iname ipt_ecn.c net/ipv4/netfilter/ipt_ECN.c net/ipv4/netfilter/ipt_ecn.c -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
Date: December 18, 2006
From: Chuck Ebbert <76306.1226@xxxxxxxxxxxxxx>
Trying to backup up a filesystem mounted via CIFS, I got these messages from tar: tar: t/2.6.10-orig/net/ipv4/netfilter/ipt_CONNMARK.c: File shrank by 1178 bytes; padding with zeros tar: t/2.6.10-orig/net/ipv4/netfilter/ipt_TCPMSS.c: File shrank by 4177 bytes; padding with zeros tar: t/2.6.10-orig/net/ipv4/netfilter/ipt_DSCP.c: File shrank by 1172 bytes; padding with zeros tar: t/2.6.10-orig/net/ipv4/netfilter/ipt_tos.c: file changed as we read it tar: t/2.6.10-orig/net/ipv4/netfilter/ipt_ECN.c: File shrank by 1638 bytes; padding with zeros tar: t/2.6.10-orig/net/ipv4/netfilter/ipt_mark.c: file changed as we read it tar: t/2.6.10-orig/net/ipv6/netfilter/ip6t_mark.c: file changed as we read it This was with kernel 2.6.19.1 SMP on x86_64, creating a tar file on a local jfs filesystem (t is the source path on a cifs mount.) Using 2.6.18.6-pre2 uniprocessor i386, with smbfs instead of cifs, everything works fine so I'm pretty sure the server is OK. Does this match any known problems? -- MBTI: IXTP
Date: December 15, 2006
From: Steve French <smfltc@xxxxxxxxxx>
In-reply-to:
<4582E339.7030006@xxxxxxxxxxxx>
References:
<4582C2D4.4010805@xxxxxxxxxx> <4582E339.7030006@xxxxxxxxxxxx>
Christopher R. Hertel wrote:
Steve French wrote:Currently the only way to do this with cifs client is to disable the Unix Extensions on the client or server (which also disables posix locking, the extended posix statfs and unix mknod).What's the switch for disabling the extensions on the client side?
I probably need to make this a mount parm, but currently users do echo 0 > /proc/fs/cifs/LinuxExtensionsEnabled mount -t cifs //server/share /mnt ... echo 1 > /proc/fs/cifs/LinuxExtensionsEnabledto achieve roughly the same effect (ie disabling the Unix Extensions for just this mount but not mounts to other servers) - it is probably better to simply
make the reporting of uid/gid/mode a property of the tree connection though so the user does not have to remember how many times they mounted to each server and with what mount parms this first time, and we don'thave to deal with checking the state of that /proc/fs/cifs/LinuxExtensionsEnabled
at reconnection time (if the network connection drops)
Also (sort of a tangent here), I've been trying to figure out how to use a CIFS share from a Samba server in a way similar to the way I can mount NFS shares. Basically, I want to be able to mount a remote CIFS share as guest, but still have full uid/gid/mode support.
Could you explain what you want in more detail?uid/gid/mode support works if the server supports the Unix extensions - mode bits are evaluated on the client (generic_permission in the vfs) - what user you choose to use to mount on the server does not really matter for the client access decision as long as you have access on the server for that share for that id specified on mount (or if you don't want to send a username you can try "sec=none" to send a null user and "guest" so it does not prompt for password)
Date: December 15, 2006
From: "Christopher R. Hertel" <crh@xxxxxxxxxxxx>
In-reply-to:
<4582C2D4.4010805@xxxxxxxxxx>
References:
<4582C2D4.4010805@xxxxxxxxxx>
Steve French wrote: > Any opinions on whether there should be a way to mount to Samba (which > supports the CIFS Unix Extensions by default) but ignore the > uid/gid/mode (and posix acls) which the server returns? For cases in > which the Samba server has different uids than the client, mounts can be > awkward, eventually we may add a way to load a uid mapping table to help > with this kind of case, but in the meantime, I have been wondering about > whether we should allow overrides of a "default uid" or gid or mode even > when Unix Extensions are negotiated. I have encountered these problems in production and they're really annoying. For a while, I even turned off the Unix extensions on the Samba side just to get around the problems I was having. > Currently the only way to do this with cifs client is to disable the > Unix Extensions on the client or server (which also disables posix > locking, the extended posix statfs and unix mknod). What's the switch for disabling the extensions on the client side? Also (sort of a tangent here), I've been trying to figure out how to use a CIFS share from a Samba server in a way similar to the way I can mount NFS shares. Basically, I want to be able to mount a remote CIFS share as guest, but still have full uid/gid/mode support. Chris -)----- -- "Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X Samba Team -- http://www.samba.org/ -)----- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)----- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)----- crh@xxxxxxxxxxxx OnLineBook -- http://ubiqx.org/cifs/ -)----- crh@xxxxxxxxx
Date: December 15, 2006
From: Steve French <smfltc@xxxxxxxxxx>
Currently the only way to do this with cifs client is to disable the Unix Extensions on the client or server (which also disables posix locking, the extended posix statfs and unix mknod).
Currently, uid, gid, and file_mode and dir_mode are ignored when the unix extensions are negotiated.
Should another mount parm be added (what would its name be?) that would cause those parms to be accepted rather than ignored? should all four be required to be filled in? Alternatively, we could allow uid, gid, file_mode and dir_mode to be accepted on mounts with the Unix extensions - but this would silently change behavior of existing clients and would make it harder for the rare case of the user who wants to use the server's uid/gid/mode if Unix Extensions are on - but if they are off on the server wants to use the default uid/gid/mode specified on mount.
Date: December 15, 2006
From: Chris Shelton <cshelton@xxxxxxxxxxx>
In-reply-to:
<4578E800.8040400@xxxxxxxxxx>
References:
<4578E800.8040400@xxxxxxxxxx>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Steve, On Thu, 7 Dec 2006 at 10:20pm, Steve French wrote: > More secure mounts, ie specifying "sec=ntlmv2" on the mount, now works to > Windows servers, not just Samba servers. > > http://master.kernel.org/git/?p=linux/kernel/git/sfrench/cifs-2.6.git;a=commitdiff_plain;h=33ec32fae0e2c4433bfd1e74cbde6cb16604a719;hp=c99767974ebd2a719d849fdeaaa1674456f5283f Actually, cifs mounts ntlmv2 to Windows servers has worked for me since you released cifs version 1.44 for older kernels (pre 2.6.17) back in June 2006. Here is a link to the note I sent several months ago, just after the release of 1.44: http://www.nabble.com/forum/ViewPost.jtp?post=5130691&framed=y chris - -- Chris Shelton - - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFgafrM5TknMKatUwRAmgbAKCXzn60DOkOny33fL9BccSJOgCQmACfd0+d qfGsZ8oS1a0NLnM5tZ/5A2U= =3+VV -----END PGP SIGNATURE-----
Date: December 14, 2006
From: Steve French <smfltc@xxxxxxxxxx>
In-reply-to:
<Pine.LNX.4.64.0612141429580.14498@xxxxxxxxxxxxxxxxxxxxxxxx>
References:
<4578E800.8040400@xxxxxxxxxx> <Pine.LNX.4.64.0612141429580.14498@xxxxxxxxxxxxxxxxxxxxxxxx>
Chris Shelton wrote:
That is good news - but my guess is that some versions of Windows are more picky about the domain name field in the NTLMSSP response depending on whether they are part of a domain, the domain controller, or standalone/workstation - perhaps based on service pack level - but in any case, I am glad it worked for more servers than I thought.-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Steve, On Thu, 7 Dec 2006 at 10:20pm, Steve French wrote:More secure mounts, ie specifying "sec=ntlmv2" on the mount, now works to Windows servers, not just Samba servers. http://master.kernel.org/git/?p=linux/kernel/git/sfrench/cifs-2.6.git;a=commitdiff_plain;h=33ec32fae0e2c4433bfd1e74cbde6cb16604a719;hp=c99767974ebd2a719d849fdeaaa1674456f5283fActually, cifs mounts ntlmv2 to Windows servers has worked for me since you released cifs version 1.44 for older kernels (pre 2.6.17) back in June 2006. Here is a link to the note I sent several months ago, just after the release of 1.44:
Date: December 14, 2006
From: "Danny Sung" <dsung@xxxxxxxxxxxxx>
In-reply-to:
<OFAA148B6D.E08C3936-ON87257241.004EDB82-86257241.004F4C31@xxxxxxxxxx>
References:
<OFAA148B6D.E08C3936-ON87257241.004EDB82-86257241.004F4C31@xxxxxxxxxx>
Shirish S Pargaonkar wrote:
Danny,We have seen this problem and are working on it. Sizes of the source and destination files are same but md5sum would report different values. I have seen this problem with large files like 500MB+.I have seen some (page) ranges in destination file filled with NUL bytes.But we have observed this problem only with copying files to Windows