Hi, On Sunday 13 March 2005 08:51, Greg Freemyer wrote:

On Sun, 13 Mar 2005 08:16:03 -0800, Randall R Schulz wrote:

...

Hi,

I just acquired a 1GB Lexar JumpDrive Sport and it came pre-formatted with a FAT-16 file system (gack!):

% file -s /dev/sdc1 /dev/sdc1: x86 boot sector, code offset 0x3c, OEM-ID "MSWIN4.1", sectors/cluster 32, root entries 512, Media descriptor 0xf8, sectors/FAT 248, hiddensectors 32, sectors 2030560 (volumes > 32 MB) , serial number 0x0, unlabeled, FAT (16 bit)

How might I go about putting a more rational file system on that device, given them my system accesses it via the whole subfs / automount business (which I really don't understand at all).

I have not had any luck coming up with a fruitful Google search on this topic.

A related question is what would be a good choice of file system for such a device? I use XFS on my hard drives, but my intuition says that this isn't necessarily the best choice for a device that I'll use to shuttle files between home and work.

Thanks in advance for any information and suggestions anyone can offer.

Randall Schulz

I would think you can just unmount it, then re-format it.

That's the whole problem. This is an automounted device. When no process is accessing it (current directory, open file, etc.), the system unmounts it and /dev/sdc1 no longer accesses that device. Or does it. Hmmm... I was under the impression that was true, but I just tried to confirm it and I find that, in fact, /dev/sdc1 apparently does persistently refer to that device. The "file -s /dev/sdc1" command shows the same results even when mount and df don't list the usb-... file system mounted in /media. So I guess that's all I really need to know.

If you need windows compatibility, I would stick with FAT, but maybe FAT32.

No. I probably don't care about Windows. But if I know how to do this, I can always reformat with FAT32 if that need arises. Since I wouldn't use this for long-term storage, only for file shuttling, frequent reformatting is not a problem.

umount /dev/sda1 mkdosfs -F 32 /dev/sda1 mount /dev/sda1 /mnt # Just as a quick test

If all you need is Linux support, I guess ext2 would be the best choice. Journaling would not make since, at least not with SUSE 9.2 because it mounts with the SYNC option that defeats the whole purpose of a jorunal.

As I said, the mounting and unmounting are handled by the system (some function of subfs, automount and possibly SuSEPlugger, too--as I said, I don't really understand this stuff at all). Thanks to you, Greg, as well as Ken and Martin Deppe (who replied privately) for putting me on to the solution that was right in front of me. Randall Schulz

Danny, On Tuesday 15 March 2005 06:45, Danny Sauer wrote:

On Sunday 13 March 2005 11:25 am, Randall R Schulz wrote:

...

Hi,

On Sunday 13 March 2005 08:51, Greg Freemyer wrote:

...

If all you need is Linux support, I guess ext2 would be the best choice. Journaling would not make since, at least not with SUSE 9.2 because it mounts with the SYNC option that defeats the whole purpose of a jorunal.

As I said, the mounting and unmounting are handled by the system (some function of subfs, automount and possibly SuSEPlugger, too--as I said, I don't really understand this stuff at all).

I'd suggest against a journaled system, largely because of the extra disk writes. Flash can be read a lot, but can't be written to indefinitely, and adding journaling just increases the writes.

I was thinking plain old extfs2, but this cramfs thing sounds interesting. What are the implications / requirements for getting it working on an otherwise stock SuSE 9.1 (with all YOU patches, including new kernels, installed)?

As an aside, I'm amazed at how well the newest kernels handle USB devices.

Hmmm... When I bought this 1GB flash-RAM "disk," I removed the old 128M version and plugged in the new one. Much confusion ensued, culminating in all processes that attempt to access the device hanging in an unkillable state. After a reboot, things were back to normal and the device can be accessed normally. Of course, I just upgraded my BIOS (subsequent to changing the flash memory stick) and one of the changes incorporated since the previous BIOS version was "Ported latest AMI USB support and also fixed USB Card reader issue." (vagueness only an engineer or a politician could create). So perhaps Linux or SuSE's packaging of it or embellishments to it are not to blame. I'm not enthusiastic about repeating this exercise, so I'll just ignore it for now.

--Danny, running cramfs on his compact-flash cards (the CPU time to decompress is more than offset by the bandwidth savings to the card), but they're used for a different purpose (booting a car mp3 player, etc)

That must be from Rio / Diamond Networks (or one of the firms it absorbed), right? I have a Rio Karma, and it's an oustanding player. Randall Schulz

On Tuesday 15 March 2005 10:23 am, Randall R Schulz wrote:

Danny,

On Tuesday 15 March 2005 08:09, Randall R Schulz wrote:

...

Danny,

...

I was thinking plain old extfs2, but this cramfs thing sounds interesting. What are the implications / requirements for getting it working on an otherwise stock SuSE 9.1 (with all YOU patches, including new kernels, installed)?

It appears cramfs is very limited, it's rather less than a full-featured Linux file system with compression. Evidently, it's actually oriented towards embedded Linux applications like your (Danny's) MP3 player.

For example (from the NOTES file included in the cramfs tools tarball):

Yeah - it's along the lines of squashfs and zisofs - most of those require pre-creating the filesystem (which is the compression stage), and then they can be read from by decompressing on the fly. Reiser4 has a transparent compression plugin, but then you're using Reiser and a journal again. If you were using this thing in a single machine, you could put the journal on a sepaarte device, but then you might as well put the files on that separate device, too. :) I wish there was a transparently compressed filesystem available for Linux that didn't also require a journal. I guess that, depending on your preferred desktop environment, you could use a .tar.gz/bz or .zip file, as KDE and Gnome, IIRC, both have a VFS plugin that'll let you treat those files as folders on the filesystem. I'm not sure if either work by unwrapping the whole file or just the part that's needed. I'm betting that you wouldn't get much of a performance gain there - though, you'd probably get decreased flash life, since the flash card couldn't balance the writes across the disk as well as it normally could. What about just gzipping everything on the card? Many (most?) utilities can directly work with gzipped files now - things like less, man, vim, etc. On my Gentoo desktop that I'm testing with, bzip'd files are transparent to those tools, too. Sadly, the GUI tools largely don't work with either. And zlib is so easy to use... --Danny, probably not a whole lot of help. :)

On Tuesday 15 March 2005 10:23 am, Randall R Schulz wrote:

It appears cramfs is very limited, it's rather less than a full-featured Linux file system with compression. Evidently, it's actually oriented towards embedded Linux applications like your (Danny's) MP3 player.

http://sources.redhat.com/jffs2/jffs2-html/ I was just building a new system for the MP3 player tonight (I'm trying for a uclibc-based setup this time), and while I was researching compressed filesystems, I stumbled across jffs2. It's a filesystem specifically designed for flash drives (spreads writes across spare blocks, to help extend the life) and has journalling and reasonable compression. It's not built into every kernel on earth by default, but it looked interesting enough that I thought I'd mention it for the sake of completeness. --Danny, using cramfs anyway, since his needs are read-only (largely to handle things like frequent unexpected power-down)

On Wed, 2005-03-16 at 23:49 -0500, B. Stia wrote:

On Sunday 13 March 2005 11:16, Randall R Schulz wrote: As a aside to this question, (excuse my ignorance) Can this be made bootable and a small OS be put on it? For a permanent kind of thing in a mobile installation. (GPS in an aircraft) Right now I am using a 1.6 gig regular hard drive. If not, how about a DOC that can be booted and then passed to the flash drive?

Bob S.

Yes, as long as your system supports booting from USB devices. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 * Only reply to the list please* "The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners." -Ernst Jan Plugge

Hi all, On Friday 18 March 2005 04:18, B. Stia wrote:

On Thursday 17 March 2005 08:39, Ken Schneider wrote:

...

On Wed, 2005-03-16 at 23:49 -0500, B. Stia wrote:

...

On Sunday 13 March 2005 11:16, Randall R Schulz wrote: As a aside to this question, (excuse my ignorance) Can this be made bootable and a small OS be put on it? For a permanent kind of thing in a mobile installation. (GPS in an aircraft) Right now I am using a 1.6 gig regular hard drive. If not, how about a DOC that can be booted and then passed to the flash drive?

Bob S.

Yes, as long as your system supports booting from USB devices.

Ken, & Chad

Read someplace (which I can't find now) that the DOC is seen and interpreted as an IDE device. Requires a change in the bios to recognize it. Problem is that most affordable DOC's are pretty small (You can get them up to a gig but they cost $ 1000's) and the small one's would only hold a small boot partition.

Now, if you could then partition the USB for the rest of the OS and application files you would have something. Maybe I am all wet here and on the wrong track, but when I saw Randall's post about the 1 Gig flash device it got me thinking.

Anyway, Bob S.

Excuse me, if i'm perhaps off-topic, but how-about flash-ide adapters, like currently on ebay (about 3 USD): http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&category=167&item=5175353997&rd=1 ( or new: http://adis.ca/cfdisk.php ) AFAIK, even the bios thinks it's an IDE-device. no drivers needed. And compact-flash are upto 2GB. Not overwhelming large compared with regular drives, but a compact system should fit on it. Hans

Bob, On Wednesday 16 March 2005 20:49, B. Stia wrote:

...

...

Thanks in advance for any information and suggestions anyone can offer.

As a aside to this question, (excuse my ignorance) Can this be made bootable and a small OS be put on it? For a permanent kind of thing in a mobile installation. (GPS in an aircraft) Right now I am using a 1.6 gig regular hard drive. If not, how about a DOC that can be booted and then passed to the flash drive?

Well, we'd prefer it if you only asked questions to which already knew the answer, but... (In that spirit, I will refrain from asking what a DOC is.) You might want to investigate the practice mentioned earlier in this thread by Danny Sauer's of using cramfs if you're looking for a read-only, compressed file system for use in an embedded device. And keep the other advice in mind, too, that a flash "disk" is still flash RAM and it sustains only a limited number of writes. So Danny's other recommendation to avoid a journalled file system is probably well considered. I'm not personally familiar with the read/write patterns of the various file systems, so I just take him at his word. Besides, the fact that for users running the stock automount system for removable media means that devices are all written synchronously (the kernel does not engage in write-behind, saving disk blocks in buffer instead of writing them as soon as the higher-level software issues the write request), so there's little to be gained from using a journalled file system. And now to a related question--Since my USB flash RAM devices have no entries in /etc/fstab, how can I specify mount options? I'd like to specify "noatime" to further reduce the number of write operations performed on that device.

Bob S.

Randall Schulz

Patrick, On Thursday 17 March 2005 07:24, Patrick Shanahan wrote:

* Randall R Schulz [03-17-05 10:03]: ...

...

And now to a related question--Since my USB flash RAM devices have no entries in /etc/fstab, how can I specify mount options? I'd like to specify "noatime" to further reduce the number of write operations performed on that device.

With a text editor, ie: 'vim /etc/fstab'

assign the proper parameters and a mount point to your liking. Critical will be the 'device' name and file system type. *If* the device name is not predictable, you cannot do what you wish.

You're not paying attention. As I wrote, "my USB flash RAM devices have no entries in /etc/fstab."

Patrick Shanahan

Randall Schulz

Ken, On Thursday 17 March 2005 08:51, Ken Schneider wrote:

On Thu, 2005-03-17 at 07:36 -0800, Randall R Schulz wrote:

...

Patrick,

You're not paying attention. As I wrote, "my USB flash RAM devices have no entries in /etc/fstab."

Randall Schulz

Then add them.

And what device name do I use?

Ken Schneider

Randall Schulz

Patrick, On Thursday 17 March 2005 09:59, Patrick Shanahan wrote:

* Randall R Schulz [03-17-05 11:55]:

hursday 17 March 2005 08:51, Ken Schneider wrote:

...

...

On Thu, 2005-03-17 at 07:36 -0800, Randall R Schulz wrote:

...

Patrick, You're not paying attention. As I wrote, "my USB flash RAM devices have no entries in /etc/fstab."

Then add them.

And what device name do I use?

Now, *while* I happen to be *paying* attention (and not meaning to be rude) you might look into /var/log/messages right after plugging in the drive and see what dev-name is assigned or check /etc/fstab after the device is auto-mounted and back trace the link assigned for the device name.

btw, /etc/fstab *is* a *dynamic* listing of device mount-points and *is* editable and *will* use mount-points *you* assign.

Not *rude*, eh? /etc/fstab is by no means dynamic. I know perfectly well it's editable. /etc/mtab records the current mounted device status it is dynamic and not meant to be edited by humans.

Patrick Shanahan

Randall Schulz

Patrick, On Thursday 17 March 2005 10:19, Patrick Shanahan wrote:

* Randall R Schulz [03-17-05 13:10]:

...

/etc/fstab is by no means dynamic.

fstab *is* dynamic as also is mtab.

Maybe on your system. Definitely not on mine.

It changes as hot-pluggable devices are added/subtracted and mtab changes as devices are mounted and/or umounted.

No. It does not. Randall Schulz

On Thursday 17 March 2005 18:59, Patrick Shanahan wrote:

Now, *while* I happen to be *paying* attention

I did /not/ in particular to this thread, but to your mail only. ;)

(and not meaning to be rude) you might look into /var/log/messages right after plugging in the drive and see what dev-name is assigned or check /etc/fstab after the device is auto-mounted and back trace the link assigned for the device name.

btw, /etc/fstab *is* a *dynamic* listing of device mount-points and *is* editable and *will* use mount-points *you* assign.

I remember a trick I used with 9.1, and it's possible it works with 9.2 too. Create a directory /events in the root directory. I think the hot and cold plug events will be logged in that directory, if it exists. IIANM, just creating /events would be enough, but perhaps the system needs a reboot...??? Maybe this is helpfull. Cheers, Leen

On Thursday 17 March 2005 19:37, Ken Schneider wrote:

Just for testing purposes (SuSE 9.2 fresh install as of lastnight) I plugged in my flash drive and did not find any entry added to /etc/fstab but there was an entry added to the end of /etc/mtab. Issue the mount command without any parameters and the info presented can be used to add and entry to fstab with minor modification. /etc/fstab is -not- meant to be dynamic where as /etc/mtab is.

I vaguely remember that at some point in time SuSE changed fstab also (in the 9.1 days???). But I think it's indeed better to not change fstab for the reason you mentioned. Cheers, Leen

On Thu, 2005-03-17 at 15:25 -0500, Patrick Shanahan wrote:

* Leendert Meyer [03-17-05 14:14]: I would guess then that there was a change after 9.0 as I get the following generated when a hotplug device is recognized:

/dev/sdg1 /media/sdg1 auto sync,noauto,user,exec 0 0 #HOTPLUG oxVZ.vQkoml3mTJ4 /dev/sdb4 /media/sdb4 auto sync,noauto,user,exec 0 0 #HOTPLUG B3Fu.AdW+w1Qx+W6 /dev/sdc1 /media/sdc1 auto sync,noauto,user,exec 0 0 #HOTPLUG _DVI.vQkoml3mTJ4

fstab is still editable and the place to define a consistant mount-point.

I *fully* intended to install 9.2 but have been toooo happy with the consistancy of 9.0. I *will* install 9.3 when my pre-order is filled! And, hopefully, onto *new* equipment, amd probably 64 bit.

I think this was changed starting in 9.1 which is better in the long run and back to the original way it was before hotplugging. I prefer it this way as it gives the user (admin) more control. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 * Only reply to the list please* "The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners." -Ernst Jan Plugge

Ken, On Thursday 17 March 2005 10:02, Ken Schneider wrote:

On Thu, 2005-03-17 at 08:54 -0800, Randall R Schulz wrote:

...

Ken,

...

Then add them.

And what device name do I use?

Issue the command dmesg after plugging in the device and see what device name it is using, probably something like /dev/sda1.

I know the device name it uses on any given mount. But it's not stable. It depends on the order in which USB mass storage devices are mounted. I want a solution that is not susceptible to this dependency.

Ken Schneider

Randall Schulz

Patrick Shanahan wrote:

* Randall R Schulz [03-17-05 17:33]:

...

I know the device name it uses on any given mount. But it's not stable. It depends on the order in which USB mass storage devices are mounted.

I want a solution that is not susceptible to this dependency.

Looks like Joe Morris (NTM) has provided an answer to your problem today in this list I didn't reply to his message because IIRC he uses 9.1 and I am not sure it will work with the udev of 9.1, but it does work with udev in 9.2. An example from mine is for a lexar jumpdrive. First, I created a file in /etc/udev/rules.d/ called 10-udev.rules (so it is not over written by an upgrade). It is: BUS="usb", SYSFS{serial}="33000000817000041501", KERNEL="sd?1", NAME="%k", SYMLINK="jumpdrive"

this produces a link to which ever sd device it gets, but is specific to this particular jumpdrive. Then I created a directory /media/jumpdrive. I also added to fstab: /dev/jumpdrive /media/jumpdrive vfat noauto,user,rw,sync 0 0 I could have used subfs, but decided I wanted to manually mount and unmount (I'm still a bit old school and can understand the safety of that better). Then, I created a device icon (.desktop) file on my desktop called Lexar Jumpdrive, choosing rw and mountpoint (of which it reads fstab and gives you the choices) /media/jumpdrive. It works great for me in 9.2, hope it still works in 9.1. -- Joe Morris New Tribes Mission Email Address: Joe_Morris@ntm.org Registered Linux user 231871

I found a good website on writing udev rules: http://www.reactivated.net/udevrules.php Daniel has some good examples in there. -- Jerry Feldman Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

On Thursday 17 March 2005 10:36, Randall R Schulz wrote:

You're not paying attention. As I wrote, "my USB flash RAM devices have no entries in /etc/fstab."

I think he was suggesting you add an entry for it into fstab, but warning you the device name must be predictable for it to work. Bryan ******************************************************** Powered by SuSE Linux 9.2 Professional KDE 3.3.0 KMail 1.7.1 This is a Microsoft-free computer Bryan S. Tyson bryantyson@earthlink.net ********************************************************