Linux-Development-Sys Digest #153, Volume #8 Sun, 17 Sep 00 23:13:09 EDT
Contents:
Re: ext2 file size limit? (Christopher Browne)
large file support ("Alexander Bruns")
Re: new windowing system ([EMAIL PROTECTED])
Re: new windowing system ([EMAIL PROTECTED])
Re: I Need A Shell Script, Or A C Program.... (Stephen Harris)
Re: Wish for a writable ISO-9660 compatible filsystem (Otto Wyss)
Re: new windowing system (Christopher Browne)
Re: Asynchcrounous read and write (Karl Heyes)
Re: Turning swap off (Karl Heyes)
Re: new windowing system (Juliusz Chroboczek)
Re: aic7xxx 2.4.0 kernel module...gone (Michael Meding)
Re: New OS Project (Neil)
Re: I Need A Shell Script, Or A C Program.... (Neal Tucker)
Re: ext2 file size limit? (Alexander Viro)
Re: new windowing system (Alexander Viro)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.misc
Subject: Re: ext2 file size limit?
Reply-To: [EMAIL PROTECTED]
Date: Sun, 17 Sep 2000 20:30:32 GMT
Centuries ago, Nostradamus foresaw a time when Robert Heller would say:
> Paul Reilly <[EMAIL PROTECTED]>,
> In a message on Sat, 16 Sep 2000 17:53:18 -0700, wrote :
>PR> Hi
>PR>
>PR> Can someone tell me what the max size for a single file is in linux?
>PR>
>PR> I'm trying to creat a 6GB loopback device, but using dd if=/dev/zero
>PR> of=file
>PR> crashes out after filling the file with 2GB. I presume this is happening
>PR> as I've reached some file system limit? Is there any way around this or
>PR> any plans on making ext2 handle larger files?
>
>This is a problem with the current i386 (32-bit) ext2 kernel code. I
>don't know if the 2.4.x kernel will fix this or not.
Could you be more specific about that? The last time I checked the
ext2 code, it merely had the same limitation as VFS + LIBC.
I expect Alexander Viro can comment on this more competently than
anyone else, as VFS is basically "his baby."
For those that don't want to go through those details should
take a look at /usr/include/stdio.h, particularly at the
call signature for fseek(stream, long int offset, int whence).
File sizes are limited by the fact that on 32 bit platforms, a
"long int" is normally 32 bits long.
And cacheing doesn't work out too well if you can't map files onto
virtual memory.
--
[EMAIL PROTECTED] - <http://www.hex.net/~cbbrowne/lsf.html>
"Bother," said Pooh, as he deleted his root directory.
------------------------------
From: "Alexander Bruns" <[EMAIL PROTECTED]>
Subject: large file support
Date: Sun, 17 Sep 2000 23:52:20 +0200
how do i actiate large file support in the 2.4.0-test8-kernel or the 2.2.x
kernel??
What packages do i have to update excpet the ones in Documentation/Chnages??
i now tried on my redhat 6.2 installation the 2.4.0-test8 an was able to
crate a tar-file greater than 2 gb
but i cannot compile samba for large file support and the samba-newsgroup
told me to setup right sopport for lfs in my linux.
Greetings
Alex
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: new windowing system
Date: Sun, 17 Sep 2000 21:49:31 GMT
In article <POWw5.15580$[EMAIL PROTECTED]>,
"John Smith" <[EMAIL PROTECTED]> wrote:
> It's "neck of the woods", idiot.
Metaphors often differ between languages,
so don't be so hard on him.
Wow, I feel so good having rescued that
guy, I was just in the neck of time!
;)
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.x,comp.windows.x
Subject: Re: new windowing system
Date: Sun, 17 Sep 2000 22:00:28 GMT
In article <[EMAIL PROTECTED]>,
Aurel Balmosan <[EMAIL PROTECTED]> wrote:
> Where can the so called performance problem be found in X11?
> Personnaly I haven't found any yet.
Your PC must be faster than mine. Of course almost any PC would
be as mine is a 486. For me, every microsecond wasted counts
since they all up quickly.
> One point I have to make: Why is everyone thinking that a socket
> (tcp/ip, unix, ...) connection is slow?
My assumption was that the process of encoding a request
into a stream of bytes, then decoding that on the other end
adds quite a bit of delay over a more straightfoward function call.
My original question (I posted the original article) was whether
putting the windowing system in a driver would be a good idea.
I don't know where the free memory for window system info
would come from necessarily (video card RAM on older systems
like mine is limited and people say kernel memory is also
quite scarce) but personally I like the idea of a driver based
windowing system.
Cheers,
uwuh
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Stephen Harris)
Subject: Re: I Need A Shell Script, Or A C Program....
Date: Sun, 17 Sep 2000 21:53:30 GMT
Michael Lauzon ([EMAIL PROTECTED]) wrote:
[ A request totally off-topic to this group ]
: to delete them all at once, or one by one. This could also be a C program. I need
:this by Monday at the
: earliest, and a week Monday at the latest.
Is that when your homework is due?
--
Stephen Harris
[EMAIL PROTECTED] http://www.spuddy.org/
The truth is the truth, and opinion just opinion. But what is what?
My employer pays to ignore my opinions; you get to do it for free.
* Meeeeow ! Call Spud the Cat on > 01708 442043 < for free Usenet access *
------------------------------
From: [EMAIL PROTECTED] (Otto Wyss)
Crossposted-To: comp.os.linux.misc
Subject: Re: Wish for a writable ISO-9660 compatible filsystem
Date: Mon, 18 Sep 2000 00:14:24 +0200
Seems there is no enthusiasm for a writable ISO-9660 solution, so I
won't do anything.
O. Wyss
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.x,comp.windows.x
Subject: Re: new windowing system
Reply-To: [EMAIL PROTECTED]
Date: Sun, 17 Sep 2000 22:37:14 GMT
Centuries ago, Nostradamus foresaw a time when [EMAIL PROTECTED] would say:
>In article <[EMAIL PROTECTED]>,
> Aurel Balmosan <[EMAIL PROTECTED]> wrote:
>
>> Where can the so called performance problem be found in X11?
>> Personnaly I haven't found any yet.
>
>Your PC must be faster than mine. Of course almost any PC would
>be as mine is a 486. For me, every microsecond wasted counts
>since they all up quickly.
There winds up being LOTS of things that "add up quickly," including:
- Number of bytes of memory consumed;
- Number of I/O requests
- Quantity of video RAM in use
486 VLB versus just about anything using PCI is quite a big deal.
PCI is a whopping lot faster, _particularly_ for graphics.
>> One point I have to make: Why is everyone thinking that a socket
>> (tcp/ip, unix, ...) connection is slow?
>
>My assumption was that the process of encoding a request
>into a stream of bytes, then decoding that on the other end
>adds quite a bit of delay over a more straightfoward function call.
>My original question (I posted the original article) was whether
>putting the windowing system in a driver would be a good idea.
>I don't know where the free memory for window system info
>would come from necessarily (video card RAM on older systems
>like mine is limited and people say kernel memory is also
>quite scarce) but personally I like the idea of a driver based
>windowing system.
Well, _immediately_ upon having a network connection involved
(e.g. - Ethernet), there's a fair bit of overhead over a straight
function call.
Aside from that, it's _not_ as intuitively obvious as it might
seem that you win a lot out of trying to push the GUI into the
kernel.
The _big_, _atrocious_ problem there is that if all this stuff
gets pushed into the kernel, that means that:
- every time an application touches the screen, there has to be a change
from user mode to kernel mode,
- the set of memory "owned" by the kernel, and thus not able to be
swapped out, grows,
- if anything goes wrong with the GUI code, the kernel may get
toasted because the critical code is running in supervisor mode/
Ring 0.
The BIG performance problems that people are running into tend to have
nothing to do with X itself, but rather with:
a) Applications that do perversely inefficient things with Motif;
b) Applications that do perversely inefficient things with GTK;
c) Applications that use Xt badly;
d) Applications that use atrocious amounts of memory in and of
themselves.
Netscape is the canonical example of a), and the blame can also get
attached to Motif, to some extent. A lot of Gnome applications,
_particularly_ some "GTK themes," are examples of b). c) and d) also
occur.
You certainly shouldn't try to run Gnome on a 486 box that maxes
out at having 16MB of RAM (4 SIMM slots that may only accept 4MB
SIMMS). Blaming the problems with that idea that on X would be silly
when at least half of the memory "overconsumed" would be due to
Gnome...
--
[EMAIL PROTECTED] - <http://www.hex.net/~cbbrowne/xbloat.html>
Giving up on assembly language was the apple in our Garden of Eden:
Languages whose use squanders machine cycles are sinful. The LISP
machine now permits LISP programmers to abandon bra and fig-leaf.
-- Epigrams in Programming, ACM SIGPLAN Sept. 1982
------------------------------
From: Karl Heyes <[EMAIL PROTECTED]>
Subject: Re: Asynchcrounous read and write
Date: Sun, 17 Sep 2000 23:45:24 +0000
In article <81f2q8.us2.ln@server>, "Klas Sehlstedt" <[EMAIL PROTECTED]>
wrote:
> Hi
>
> Does linux have support for asynchrounus read and write.
>
As far as I know aio stuff is implemented in glibc 2.1. kernel improvements
are coming in 2.4 for it, but 2.2 should work.
karl
------------------------------
From: Karl Heyes <[EMAIL PROTECTED]>
Subject: Re: Turning swap off
Date: Sun, 17 Sep 2000 23:58:43 +0000
In article <MG2x5.10800$[EMAIL PROTECTED]>, "H�kan"
<[EMAIL PROTECTED]> wrote:
> Hi List
>
> What happend if I turning swap offt? Should I see any preformace downloads?
> Not so good network preformance? Does anyone know?
>
turning swap off means that run-time allocated pages of memory, like from
malloc will stay in memory even when not used (read netscape), program pages
get read back back from disk anyway!. So depending on how much memory you
have and the applications in use will affect things like caching, and
therefore indirectly affect system performance.
> Second question: How do I turn the swap off. Is it enough to remove the swap
> entry in
> /etc/fstab
> or do I have to do more?? Probebly you wonder why do that... ... I working
> with a embedded Linux system!
>
fstab in general is a table of filesystems that can be mounted. At boot it is
scanned, both with mount and swapon, but it doesn't represent a snapshot of
the memory/filesystem configuration. You need to swapoff explicity any swap
areas to make them inactive. If you swapoff when there are pages in the swap
area then the system has be do a bit of shuffling.
karl.
------------------------------
From: Juliusz Chroboczek <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.x,comp.windows.x
Subject: Re: new windowing system
Date: 18 Sep 2000 00:41:33 +0100
[EMAIL PROTECTED]:
U> My assumption was that the process of encoding a request into a
U> stream of bytes, then decoding that on the other end adds quite a
U> bit of delay over a more straightfoward function call.
You are of course right.
However, a better way to tackle the issue is through benchmarks and
profiling, rather than common sense.
Most groups developing X servers compete on the basis of x11perf
statistics. x11perf computes the time taken by graphic operations as
part of a large stream; it is just a benchmark, but one that most
definitely is indicative of rendering performance.
There has been a certain amount of research done on the performance of
shared memory transports, by HP, SGI, Sun, IBM, PI and probably others
I'm not aware of. As all experimental results, these should be taken
with a grain of salt: in particular, all were done on an unloaded
single-processor machine. Tradeoffs for SMP, or for loaded machines,
on systems that are not monolitic Unices, or for benchmarks other than
x11perf might be different.
Anyway, at least the HP, Sun and PI studies pointed at the same
conclusion: except in the particular case of large images, the
difference in speed between Unix domain sockets is within a few
percent; in other words, just not worth spending a lot of time
optimising the transport overhead when there are so many other things
to optimise. And there are other problems with shared memory
transports.
If you think about this result, it's really not surprising. X is
fundamentally a reliable stream protocol; unless the kernel people are
doing something fundamentally wrong, the X server should not be able
to significantly outperform the kernel's implementation of local
reliable streams.
(The case of large images is adequately handled by the MIT-SHM
extension, which is pretty much ubiquitous, and so it's really not an
issue you should be worried about.)
Of course, introducing a shared memory transport is only half the
story, as you still need to make context switches between the client
and the server. The question of how much time is spent in context
switches is still open, but at least Linux is pretty good at making
context-switches fast.
Much of the performance loss that you claim to be seing is probably
due to other issues. For example, you may be using a rather
pixmap-intensive window-manager (say, one that starts with E). Or
else you may be using a popular toolkit which happens to have a lot of
inefficient themes (the default themes tend to be okay, though).
(This is not to criticise the window-manager in question; I believe it
is an amazing achievement, but a program that should be reserved to
fast machines with a thick bus.)
On a side note, someone in this thread mentioned that DRI beats
indirect GLX rendering. Clearly, the tradeoffs are different for core
X rendering and for OpenGL. In particular, it is not rare for an
OpenGL application to push megabytes of data to the video chipset for
every single frame; core X has much more modest bandwidth
requirements. (Except in the case of large pixmaps, but then see the
comments above.)
With sincere regards and restricted followups,
Juliusz Chroboczek
------------------------------
From: Michael Meding <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.misc,comp.os.linux.setup
Subject: Re: aic7xxx 2.4.0 kernel module...gone
Date: Mon, 18 Sep 2000 02:20:51 +0200
Reply-To: [EMAIL PROTECTED]
Hi Jeremy,
> I am using the 2.4.0-test7 kernel and I amusing the aic7xxx drivers with
> no problem. However, I have the drivers compile into the kernel, not
> loaded as a module. I made that mistake once and my machine would not
> boot. After reading the docs in the Documentation tree of the new kernel
> it clearly states **NOT** to load any of the SCSI stuff as a module if
> that is where you boot from.
That is not true. You can use for example the aic7x module with an
initial ramdisk (you have to mkinitrd and specify it in lilo.conf) and
then boot up the system through a aic7x based controller without hassle.
RedHat uses this as standard on (all?) their distros.
For myself I do not see advantages in this behaviour so I use compiled
in support also, but this is a question of gusto.
Greetings
Michael
That was a X-post, wasn't it ?
------------------------------
From: Neil <[EMAIL PROTECTED]>
Crossposted-To: comp.os.minix
Subject: Re: New OS Project
Date: Mon, 18 Sep 2000 12:00:44 +1200
Reply-To: [EMAIL PROTECTED]
Maybe he's just trying to learn something. Learning more things is
something nobody should do without. :)
[EMAIL PROTECTED] wrote:
>
> Why not just use Linux? It's easier and more economical than
> reinventing the wheel.
>
> Also, why are you interested in NC's and internet terminals,
> is your employer trying to produce one?
>
> uwuh
>
> In article <8p5n2a$sdi$[EMAIL PROTECTED]>,
> "Gatien Gillon" <[EMAIL PROTECTED]> wrote:
> > I was thinking on writing a new Operating System based on Minix 2.0.
> The OS
> > would be aimed at Internet Terminals and Network Computers.
------------------------------
From: [EMAIL PROTECTED] (Neal Tucker)
Subject: Re: I Need A Shell Script, Or A C Program....
Date: 17 Sep 2000 19:19:50 -0700
Michael Lauzon <[EMAIL PROTECTED]> wrote:
>I need a shell script to run as root, it will search all the users who
>have MP3s, list there usernames, list the MP3s, and delete them if I so
>desire. So, what I am looking for is as follows. A program that
>searches, lists each user with a number before their username, which
>then the program will let me choose which user by number (or name),
>list all the MP3s that the user has and asks me if I want to delete
>them all at once, or one by one. This could also be a C program. I
>need this by Monday at the earliest, and a week Monday at the latest.
Ok, I'm done. Email me and I'll tell you where to send a check to
receive the program. We can haggle on the price.
-Neal Tucker
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Crossposted-To: comp.os.linux.misc
Subject: Re: ext2 file size limit?
Date: 17 Sep 2000 22:28:32 -0400
In article <[EMAIL PROTECTED]>,
Christopher Browne <[EMAIL PROTECTED]> wrote:
>>This is a problem with the current i386 (32-bit) ext2 kernel code. I
>>don't know if the 2.4.x kernel will fix this or not.
>
>Could you be more specific about that? The last time I checked the
>ext2 code, it merely had the same limitation as VFS + LIBC.
>
>I expect Alexander Viro can comment on this more competently than
>anyone else, as VFS is basically "his baby."
Sigh... Rewrite of the data side of things (pagecache and firends) is
the work of Ingo. Main part had been done circa 2.3.7-2.3.9.
Limitations were more on VM side, BTW - when pages became indexed by
page number instead of offset (i.e. by offset/PAGE_CACHE_SIZE) all mess
with long long went away. Resulting limit (on 32bit boxen): 2G pages, i.e. 8Tb.
Changes on filesystem side were "OK, now we can drop this check protecting
us from creation of files we couldn't handle"
So it's rather libc+VM problem.
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Crossposted-To: comp.os.linux.x,comp.windows.x
Subject: Re: new windowing system
Date: 17 Sep 2000 22:45:58 -0400
In article <[EMAIL PROTECTED]>,
Christopher Browne <[EMAIL PROTECTED]> wrote:
>Aside from that, it's _not_ as intuitively obvious as it might
>seem that you win a lot out of trying to push the GUI into the
>kernel.
>
>The _big_, _atrocious_ problem there is that if all this stuff
>gets pushed into the kernel, that means that:
>
>- every time an application touches the screen, there has to be a change
> from user mode to kernel mode,
Yes? You know the way to do context switch without getting into the kernel
mode in process?
>- the set of memory "owned" by the kernel, and thus not able to be
> swapped out, grows,
Depends.
>- if anything goes wrong with the GUI code, the kernel may get
> toasted because the critical code is running in supervisor mode/
> Ring 0.
Now, wait a minute. Pushing X into the kernel is horrible, indeed, but
X is not the only architecture out there. ISTR seeing you on a certain
maillist, do you mean that you didn't actually try to run the system? In cases
of rio and eight-and-half you don't have the window system in the kernel.
Rendering engine is there, but that's it. Window system acts as a multiplexor
for graphical console devices and it's in the userland (and pretty small, BTW).
Having the graphical console in the kernel doesn't strike me as something
too horrible. And yes, it can be easily made network-transparent, so it's
not localhost-only.
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
