Re: New Zaurus Wishlist - removable media handling

Re: New Zaurus Wishlist - removable media handling

[David Golden]

> And Unix filesystems were NOT designed for removable media.
>

(LKML cc'd because this rant *might* be coherent enough to explain it
to Linux kernel hackers)

The main problem I have with the Linux filesystems is this:

Forcing the user to think about which drive he stuck a disk or other
removable medium into each time he wants to access it is silly - people
often think of the disk as an entity independent of whichever drive it 
happens to be in at the time.

It drives me crazy^Hier when software insists on its cdrom being /mnt/cdrom,
for example  - there should be some way for the software to ask for
"Give me a disk called xyzzy1, and I don't care what drive it is!", and 
preferably by just trying to open e.g. /mnt/xyzzy1/

Once you've worked with a system that simply doesn't give a damn 
what drive you put a removable disk into, or even lets you pretend an 
arbitrary directory in the filesystem is that disk, it's very difficult to be 
comfortable on ones that do give a damn.  

Accessing the removable medium by the volume name of the medium, _not_
  (or not solely) by the drive it is in is something that the AmigaOS (the 
"classic" AmigaOS, not the Intent platform plastered with Amiga-trademarks) 
got "right", and Linux and Windows tend to get "wrong". (note the inverted 
commas - "right" and "wrong" are merely my opinion as a one-time Amiga 
user and now as a desktop linux user)

Amigas handled this with Assigns / amiga-style logical volumes (distinct from 
unix/linux LVMs, which are block-level) - if you stuck a CD named xyzzy1 in 
drive CD0:, you could access it via "CD0:" - "the volume currently in drive 
CD0:, whatever it may be called" , or via "xyzzy1:" - " the volume called 
xyzzy1, whatever drive it may be in"

Yes, this could be (fairly) trivially accomplished by a daemon managing a few
symlinks, or (better) the kernel automounter combined with the Linux vfs's 
support for multiple mounts of the same filesystem in different places.  

Unfortunately, there's no standard for it, and no desktop distros implement 
one, preferrring to have half-assed ad-hoc code in installers. (AFAIK on 
windows too, installers and individual applications for the most part write 
ad-hoc code to retreive the volume name, after scanning for drives.  That's 
not general or scaleable...)
 
obZaurus: The Zaurus, of course, inherits just the same problem, as far as I 
can tell -  /mnt/cf is whatever compact flash card happens to be in at the 
time, there's no direct way to ask the linux filesystem for a particular 
removeable medium. 

Re: New Zaurus Wishlist - removable media handling

[Tomasz Rola]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 27 Jun 2002, David Golden wrote:

> 
> > And Unix filesystems were NOT designed for removable media.
> >
> 
> (LKML cc'd because this rant *might* be coherent enough to explain it
> to Linux kernel hackers)
> 
> The main problem I have with the Linux filesystems is this:
> 
> Forcing the user to think about which drive he stuck a disk or other
> removable medium into each time he wants to access it is silly - people
> often think of the disk as an entity independent of whichever drive it 
> happens to be in at the time.
> 
> It drives me crazy^Hier when software insists on its cdrom being /mnt/cdrom,
> for example  - there should be some way for the software to ask for
> "Give me a disk called xyzzy1, and I don't care what drive it is!", and 
> preferably by just trying to open e.g. /mnt/xyzzy1/
> 
> Once you've worked with a system that simply doesn't give a damn 
> what drive you put a removable disk into, or even lets you pretend an 
> arbitrary directory in the filesystem is that disk, it's very difficult to be 
> comfortable on ones that do give a damn.  
> 
> Accessing the removable medium by the volume name of the medium, _not_
>   (or not solely) by the drive it is in is something that the AmigaOS (the 
> "classic" AmigaOS, not the Intent platform plastered with Amiga-trademarks) 
> got "right", and Linux and Windows tend to get "wrong". (note the inverted 
> commas - "right" and "wrong" are merely my opinion as a one-time Amiga 
> user and now as a desktop linux user)
> 
> Amigas handled this with Assigns / amiga-style logical volumes (distinct from 
> unix/linux LVMs, which are block-level) - if you stuck a CD named xyzzy1 in 
> drive CD0:, you could access it via "CD0:" - "the volume currently in drive 
> CD0:, whatever it may be called" , or via "xyzzy1:" - " the volume called 
> xyzzy1, whatever drive it may be in"

As a former Amiga user and now yet another Linux user, I probably know
what you mean. Well, I'm not a kernel engineer but maybe it could be done
with a virtual fs like /dev - so that

1. /dev/ is not polluted
2. /mnt and other real disk space is not polluted

Having something under, say, /namespace (or, maybe /proc/namespace) could
be better than having CD0: or VirtualWhatever: and would allow to
integrate the concept into the unix way of thinking while retaining the
functionality you mean.

Of course this would also mean a new API related to the namespaces, and
they could be interfaces not only to cdroms but to IPC, for example. And,
the developers would have to be convinced to use the API :-). But speaking
only for myself, I think this is nice idea.

bye
T.

- --
** A C programmer asked whether computer had Buddha's nature.      **
** As the answer, master did "rm -rif" on the programmer's home    **
** directory. And then the C programmer became enlightened...      **
**                                                                 **
** Tomasz Rola          mailto:tomasz_rola@bigfoot.com             **

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv

iQA/AwUBPRptHBETUsyL9vbiEQLWywCdENRRHIeCpNO6UnT1BAOBsTkFLkMAoIGu
aPrmfsYUaaq8yRj1FEQdrRUo
=wQik
-----END PGP SIGNATURE-----

kernel: journal /ext3 problem. "Assertion failure"

[louie miranda]

Jun 26 05:16:56 chsvr kernel: Assertion failure in
journal_commit_transaction() at commit.c:535: "buffer_jdirty(bh)"
Jun 26 05:16:56 chsvr kernel: ------------[ cut here ]------------
Jun 26 05:16:56 chsvr kernel: kernel BUG at commit.c:535!
Jun 26 05:16:56 chsvr kernel: invalid operand: 0000
Jun 26 05:16:56 chsvr kernel: iptable_filter ip_tables eepro100 usb-ohci
usbcore ext3 jbd aic7xxx sd_mod scs
Jun 26 05:16:56 chsvr kernel: CPU:    1
Jun 26 05:16:56 chsvr kernel: EIP:    0010:[<f88540e4>]    Not tainted
Jun 26 05:16:56 chsvr kernel: EFLAGS: 00010286
Jun 26 05:16:56 chsvr kernel:
Jun 26 05:16:56 chsvr kernel: EIP is at journal_commit_transaction [jbd]
0xb04 (2.4.18-3smp)
Jun 26 05:16:56 chsvr kernel: eax: 0000001c   ebx: 0000000a   ecx: c02eee60
edx: 00003684
Jun 26 05:16:56 chsvr kernel: esi: f7376b80   edi: f7271f00   ebp: f75aa000
esp: f75abe78
Jun 26 05:16:56 chsvr kernel: ds: 0018   es: 0018   ss: 0018
Jun 26 05:16:56 chsvr kernel: Process kjournald (pid: 191,
stackpage=f75ab000)
Jun 26 05:16:56 chsvr kernel: Stack: f885aeee 00000217 f74d2eb8 00000000
00000fbc f1745044 00000000 f23a2460
Jun 26 05:16:56 chsvr kernel:        f6558610 00001a64 00000001 f882ad2f
f74d2e00 00000008 f1905260 edec9560
Jun 26 05:16:56 chsvr kernel:        edec95c0 edec9620 edec9680 edec96e0
edcbc9e0 edcbca40 edcbcaa0 edcbcb00
Jun 26 05:16:56 chsvr kernel: Call Trace: [<f885aeee>] .rodata.str1.1 [jbd]
0x26e
Jun 26 05:16:56 chsvr kernel: [<f882ad2f>] rw_intr [sd_mod] 0x20f
Jun 26 05:16:56 chsvr kernel: [<c0119048>] schedule [kernel] 0x348
Jun 26 05:16:56 chsvr kernel: [<f88567d6>] kjournald [jbd] 0x136
Jun 26 05:16:56 chsvr kernel: [<f8856680>] commit_timeout [jbd] 0x0
Jun 26 05:16:56 chsvr kernel: [<c0107286>] kernel_thread [kernel] 0x26
Jun 26 05:16:56 chsvr kernel: [<f88566a0>] kjournald [jbd] 0x0
Jun 26 05:16:56 chsvr kernel:
Jun 26 05:16:56 chsvr kernel:
Jun 26 05:16:56 chsvr kernel: Code: 0f 0b 5a 59 6a 04 8b 44 24 18 50 56 e8
4b f1 ff ff 8d 47 48





Hi, i've encountered this error yesterday.
The machine dont run anything big and its
not yet on production.

The machine hangs, and does not accept some
connections on some apps like ssh, etc.

I tried to reboot the machine, and after it works
fine again.

Im not sure where to send it, and not sure
if its redhat problem or the main kernel.



BTW: its redhat 7.3
Kernel 2.4.18-3smp
A default install so far.


Please advise,
louie...

Re: New Zaurus Wishlist - removable media handling

[David D. Hagood]

Tomasz Rola wrote:

> As a former Amiga user and now yet another Linux user, I probably know
> what you mean. Well, I'm not a kernel engineer but maybe it could be done
> with a virtual fs like /dev - so that

This sounds like autofs - you'd just need a program to scan all 
available removable block devices, and look for a "label" to ID the 
media - either a (V)FAT label, or an EXT(23) label, or XFS label, or....

Then you mount the named volume as needed, with a 10 second umount 
timeout, so that you can remove it easily.

No need to add stuff to the kernel, it's already there.

Re: New Zaurus Wishlist - removable media handling

[Xavier Bestel]

Le jeu 27/06/2002 à 04:18, David D. Hagood a écrit :
> Tomasz Rola wrote:
> 
> > As a former Amiga user and now yet another Linux user, I probably know
> > what you mean. Well, I'm not a kernel engineer but maybe it could be done
> > with a virtual fs like /dev - so that
> 
> This sounds like autofs - you'd just need a program to scan all 
> available removable block devices, and look for a "label" to ID the 
> media - either a (V)FAT label, or an EXT(23) label, or XFS label, or....
> 
> Then you mount the named volume as needed, with a 10 second umount 
> timeout, so that you can remove it easily.

timeouts are *evil*. 

Re: New Zaurus Wishlist - removable media handling

[David D. Hagood]

Xavier Bestel wrote:

> timeouts are *evil*. 
> 

Since the PC has no way of knowing when you eject the disk (for 
floppies) you have to have a timeout, so that the data gets flushed.

For CD's you need a timeout to unlock the drive, otherwise the user hits 
the eject button and nothing happens - you have to unlock the drive for 
eject.

I'm not saying you automatically EJECT the disk - just unmount it, or 
mount it RO so that the user can remove it without harm.

Re: New Zaurus Wishlist - removable media handling

[Tomasz Rola]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 26 Jun 2002, David D. Hagood wrote:

> Tomasz Rola wrote:
> 
> > As a former Amiga user and now yet another Linux user, I probably know
> > what you mean. Well, I'm not a kernel engineer but maybe it could be done
> > with a virtual fs like /dev - so that
> 
> This sounds like autofs - you'd just need a program to scan all 
> available removable block devices, and look for a "label" to ID the 
> media - either a (V)FAT label, or an EXT(23) label, or XFS label, or....

Well, from what I know about autofs, it is only for filesystem things.

After reading the original post from David Golden
<david.golden@unison.ie>, I came to the "idea extension", so that apps on
the same computer could share different resources by name - be it not only 
mounted media but device files from /dev, IPC sockets or memories etc,
maybe even pids like /namespace/pids/apache_main. I don't know if this is
valuable idea or not and to really assess it there should be some
implementation with example applications using it.

I mention apps "on the same computer", because distributing such thing
over the network (LAN, I mean) is rather different subject and not
necessarily related to the kernel (I would say, it's not related and it's
not good to distribute internal kernel information by the means offered
in the kernel itself).

Myself, from time to time I do analyse some problems (involving
cooperating processes and other such beasts) and I come to the conclusion,
that the "problems" could be seen in different light when one assumes
existence of such, say, Kernel Name Service. Whether the "problems" can be
solved with less work thanks to such service I don't know yet. My analyses
are very generic at the moment :-).

> Then you mount the named volume as needed, with a 10 second umount 
> timeout, so that you can remove it easily.

One thing I really disliked in the GOAs (Good Old Amigas) was the clicking
floppy drive. This came from Amiga constantly checking if the user has
just inserted the floppy into the drive (and it could be turned off but
this wasn't always good to do so, the other trick was to have a floppy
constanlty inserted...).

And don't like the idea of automounting so I don't use it and hence I
don't know it this one clicks too or not.

> No need to add stuff to the kernel, it's already there.

Of course, everything can be done with the use of simpler means, like
semaphores can be done in the filesystem by creating and removing files
:-)...

And on the other hand, when a new API is introduced there is a lot of
issues related to access control I think, so I can understand people's
reluctance to add new functionality.

bye
T.

- --
** A C programmer asked whether computer had Buddha's nature.      **
** As the answer, master did "rm -rif" on the programmer's home    **
** directory. And then the C programmer became enlightened...      **
**                                                                 **
** Tomasz Rola          mailto:tomasz_rola@bigfoot.com             **

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv

iQA/AwUBPRsWXRETUsyL9vbiEQJx6QCg1AODJRZKJn/CVVjfFnIAXnRa7PkAmQHM
8jM03lc06tdqDwVGMNYWkbMH
=VGRX
-----END PGP SIGNATURE-----

Re: [Zaurus-general] Re: New Zaurus Wishlist - removable media handling

[Larry Garfield]

Tomasz Rola wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Thu, 27 Jun 2002, David Golden wrote:
> 
> >
> > > And Unix filesystems were NOT designed for removable media.
> >
> > (LKML cc'd because this rant *might* be coherent enough to explain it
> > to Linux kernel hackers)
> >
> > The main problem I have with the Linux filesystems is this:

<snippink>

> As a former Amiga user and now yet another Linux user, I probably know
> what you mean. Well, I'm not a kernel engineer but maybe it could be done
> with a virtual fs like /dev - so that
> 
> 1. /dev/ is not polluted
> 2. /mnt and other real disk space is not polluted

Well, I am neither a former Amiga user nor a kernel developer (but
GNU/Linux user), so I understood MOST of what you two said. ;-)  Coming
from a user-angle, though, the main problem with the Linux file system
"style", for lack of a better word, is the unified file tree.  

What?  The unified file tree?  Yes, the unified file tree.  The idea
that the silver plastic round thing you just put into the front of the
computer is accessed.... "under" the "storage" in the computer?  Does
that, conceptually, metaphorically, make sense?  No, it doesn't.  Nor
does the need to explicitly "mount" and "umount" (the n having gotten
lost while moving from one office to another a few years back) a floppy
disk.  This is one place where, I hate to say it, drive letters a la
DOS/Windows (or some other top-level identifier) are significantly
better from a user perspective.

-- 
Larry Garfield			AIM: LOLG42
lgarfiel@students.depaul.edu	ICQ: 6817012

-- "If at first you don't succeed, skydiving isn't for you." :-)

Re: [Zaurus-general] Re: New Zaurus Wishlist - removable media handling

[Kent Sandvik]

No, to be fair, that could be easily emulated with mount points such as 
/HD, /CF-card, /SD-card, and so forth. But one issue in this all is to 
even hide the file system for the end users, and only indicate the 
location for the data, i.e. 'this picture is on the SD card you just 
plugged in', and so forth. --Kent

On Wednesday, June 26, 2002, at 07:38 PM, Larry Garfield wrote:

> What?  The unified file tree?  Yes, the unified file tree.  The idea
> that the silver plastic round thing you just put into the front of the
> computer is accessed.... "under" the "storage" in the computer?  Does
> that, conceptually, metaphorically, make sense?  No, it doesn't.  Nor
> does the need to explicitly "mount" and "umount" (the n having gotten
> lost while moving from one office to another a few years back) a floppy
> disk.  This is one place where, I hate to say it, drive letters a la
> DOS/Windows (or some other top-level identifier) are significantly
> better from a user perspective.

Re: [Zaurus-general] Re: New Zaurus Wishlist - removable media handling

[Denis Vlasenko]

On 27 June 2002 00:38, Larry Garfield wrote:
> What?  The unified file tree?  Yes, the unified file tree.  The idea
> that the silver plastic round thing you just put into the front of the
> computer is accessed.... "under" the "storage" in the computer?  Does
> that, conceptually, metaphorically, make sense?  No, it doesn't.

"Programmatically" it makes a lot of sense.

Do you see any fundamental difference in
A:\dir\dir
B:\dir\dir
 and
/mnt/auto/fd0/dir/dir
/mnt/auto/fd1/dir/dir
 from user POV?

> Nor
> does the need to explicitly "mount" and "umount" (the n having gotten
> lost while moving from one office to another a few years back) a floppy
> disk.  This is one place where, I hate to say it, drive letters a la
> DOS/Windows (or some other top-level identifier) are significantly
> better from a user perspective.

You can live without mount/umount. Automounter is your friend.

It is theoretically possible to teach filesystems to sync dirty
data to removable media ASAP and to cope with diskettes being removed without 
umount ("no disk? do we have diryt buffers? no? ok, implicit umount").
Who's volunteering to do that is an open question. :-)

I live with automounter with short umount timeout.
--
vda

Re: [Zaurus-general] Re: New Zaurus Wishlist - removable media handling

[Horst von Brand]

Larry Garfield <lgarfiel@students.depaul.edu> said:

[...]

> Well, I am neither a former Amiga user nor a kernel developer (but
> GNU/Linux user), so I understood MOST of what you two said. ;-)  Coming
> from a user-angle, though, the main problem with the Linux file system
> "style", for lack of a better word, is the unified file tree.

Right. Something like mtools(1) for isofs would be nice...
--
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Vin~a del Mar, Chile                               +56 32 672616