bug in beta Windows 7 client

33 views
Skip to first unread message

Günther Thomsen

unread,
May 6, 2013, 12:37:22 AM5/6/13
to XtreemFS
I just downloaded and installed the client for MS Windows and
installed it on a x86_64 box sporting Windows 7. Basic functionality
seems to work (I can connect to the demo server, download the movie),
but if I mount a fs from a directory server on the LAN, the client
bails out (mount.xtreemfs exits, network drive is unmounted, no error
messages but in the event log I find the exception listed below) once
I enter a directory (using MS explorer) which holds some 1,700 files.

The client on Linux (Ubuntu 12.04) doesn't seem to have difficulties
with that fs or directory.

Event log entry:
--8<--
- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/
event">
- <System>
<Provider Name="Application Error" />
<EventID Qualifiers="0">1000</EventID>
<Level>2</Level>
<Task>100</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2013-05-06T04:18:38.000000000Z" />
<EventRecordID>25104</EventRecordID>
<Channel>Application</Channel>
<Computer>buntje</Computer>
<Security />
</System>
- <EventData>
<Data>mount.xtreemfs.exe</Data>
<Data>0.0.0.0</Data>
<Data>50a10e5e</Data>
<Data>mount.xtreemfs.exe</Data>
<Data>0.0.0.0</Data>
<Data>50a10e5e</Data>
<Data>c0000005</Data>
<Data>00008f28</Data>
<Data>ff8</Data>
<Data>01ce4a10c291d66b</Data>
<Data>C:\Program Files (x86)\XtreemFS Windows Client
\mount.xtreemfs.exe</Data>
<Data>C:\Program Files (x86)\XtreemFS Windows Client
\mount.xtreemfs.exe</Data>
<Data>066862c4-b604-11e2-a4d5-000e0c8557b2</Data>
</EventData>
</Event>
-->8--

hth
~ Guenther

Michael Berlin

unread,
May 6, 2013, 1:03:06 PM5/6/13
to xtre...@googlegroups.com
Hi Guenther,

Thanks for the report.

Can you please play with the mount.xtreemfs.exe parameter
--readdir-chunk-size and see if the client still crashes? The parameter
defaults to 1024 directory entries. Can you please increase it above
your 1700 files count e.g. 2048?

If this doesn't change anything, I'd like to reproduce the issue and
debug the code. Therefore I would appreciate it if could you provide me
an archive of the file names or instructions how to reproduce it.

Best regards,
Michael

guen...@gmail.com

unread,
May 7, 2013, 11:30:18 PM5/7/13
to xtre...@googlegroups.com
On Monday, May 6, 2013 10:03:06 AM UTC-7, Michael Berlin wrote:
Hi Guenther,

Thanks for the report.

Thanks for the quick replay :)
 
Can you please play with the mount.xtreemfs.exe parameter
--readdir-chunk-size and see if the client still crashes? The parameter
defaults to 1024 directory entries. Can you please increase it above
your 1700 files count e.g. 2048?

I did just that and now it seems to work, thank you.
minor nitpick: displaying only the first <n> entries in a moderately large directory would be OK in many cases (interactive client, like Windows Explorer), I'd think, bailing out when such a directory is encountered not so.
 
If this doesn't change anything, I'd like to reproduce the issue and
debug the code. Therefore I would appreciate it if could you provide me
an archive of the file names or instructions how to reproduce it.

That was just a basic test -- I copied /usr/lib from a (small) Linux box (Mint 13, I believe) -- some 22,000 files total / 1070 in the base directory (sorry for the typo above).

~ Guenther 

Michael Berlin

unread,
May 8, 2013, 12:07:05 PM5/8/13
to xtre...@googlegroups.com
Hi Guenther,

On 05/08/2013 05:30 AM, guen...@gmail.com wrote:
> On Monday, May 6, 2013 10:03:06 AM UTC-7, Michael Berlin wrote:
>
> Hi Guenther,
>
> Thanks for the report.
>
> Thanks for the quick replay :)
>
> Can you please play with the mount.xtreemfs.exe parameter
> --readdir-chunk-size and see if the client still crashes? The parameter
> defaults to 1024 directory entries. Can you please increase it above
> your 1700 files count e.g. 2048?
>
> I did just that and now it seems to work, thank you.

Thanks for the confirmation.

> minor nitpick: displaying only the first <n> entries in a moderately
> large directory would be OK in many cases (interactive client, like
> Windows Explorer), I'd think, bailing out when such a directory is
> encountered not so.

No, of course not. Clearly, it's a bug. I created an issue for it:
http://code.google.com/p/xtreemfs/issues/detail?id=286

I'll look into it next week.

Currently, we do not have automated tests for the Windows client -
otherwise such a problem would have been spotted earlier. If somebody is
interested in extending our python-based integration test framework for
Windows, he can contact me.

Best regards,
Michael

>
> If this doesn't change anything, I'd like to reproduce the issue and
> debug the code. Therefore I would appreciate it if could you provide me
> an archive of the file names or instructions how to reproduce it.
>
> That was just a basic test -- I copied /usr/lib from a (small) Linux box
> (Mint 13, I believe) -- some 22,000 files total / 1070 in the base
> directory (sorry for the typo above).
>
> ~ Guenther
>
> --
>
> ---
> You received this message because you are subscribed to the Google
> Groups "XtreemFS" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to xtreemfs+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
Reply all
Reply to author
Forward
0 new messages