I have a laptop on order and am planning the install of Slackware, Fedora, and Umbuntu on flash drives. I am currently running Slackware 13.37 partitioned as shown here:
The laptop has 2 USB-2 ports, but will probably use 1 port at a time. I will be multi-booting and in order to minimize "sdc" writes, it is currently my plan to put /boot, /usr, and /sbin for each distro on a flash drive and /root, /opt, /var, /home, and /tmp on the hard drive, in separate partitions for each distro.
I am wondering if there might be a better way to configure to leave most of the read only system code on the flash drive. The purpose of this is to improve the life of the flash drives.
Thanks for UR suggestions

/boot, /usr, and /sbin are relatively small in comparison to your data; so you're not really offloading some huge amount of information to somewhere you intend to protect.

Splitting hairs I know, but you're not going to "extend the life" of a flash drive, it's life is determined by the statistical amount of write cycles it can sustain; therefore in that - newer is better because as hardware technology improves, the amount of write cycles a re-writeable flash drive can sustain gets better. What you're looking to do is extend the "use period" for your flash drives.

What you say seems a valid assumption and my guess is that you intend to try to mount those partitions as read-only?

I merely suspect that while you find you "can" do this, the overhead of management of this, especially with multiple distributions, will not be worth your time.

At the very least, mount them with the "noatime" option.

2 members found this post helpful.

Modern flash drives already have accounted for ths, by leaving a portion of the drive unused, and available only as cells die. Your flash drive will be long obsolete before it wears out. I still have a number of 256MB flash drives around, fully functional, but unused because they're too small to be worth bothering with. Same with 512MB, 1GB, 2GB, etc. Flash memory, even older devices, simply don't wear out quickly enough for the average user to be concerned about it. Use whatever drive you have, and get on with life. I agree with using the 'noatime' option, because for most people, logging the last time a file was accessed is a waste of time and energy anyway, and that does do something to reduce wear.

1 members found this post helpful.

Hi there,

while that may be true for many of them (and many people's usage habits), you shouldn't generalize. So far, there were three USB flash drives I had to retire because they were beginning to fail. One of them a fairly new no-name 8GB stick, the other two 4GB CnMemory, but different models. All of them caused disk I/O errors at an increasing frequency, along with corruption of stored data (no actual data loss, because I always have that data somewhere safe). The two CnMemory's were about four and six years old when they started to break down, both were in use as a "big floppy" almost daily. That means: No extensive, permanent write access, just copy a few files on it each day to carry these files between multiple PCs.

I agree entirely. And I may add: Always make sure that you have a safe backup of what you hope to have on the flash drive.

[X] Doc CPU

As a good tip I would also recommend you learn to use mknod to create static /dev points to keep udev from writing device nodes and use fstab for mounting to avoid over usage of udisks and udev as much as possible.

An excellent suggestion. I remember making the appropriate entries to /etc/fstab back in the day before udisks/udev became ubiquitous, but quit once auto-mounting became easier. However, given the increased time in mounting/umounting flash drives, I have become a bit concerned. I have noticed, however, that giving my flash drive a fixed mountpoint has dramatically decreased the time to mount or umount. I am very pleased.

As a side note, I have come to believe that udisks/udev are somewhat temperamental and, as a result, should be avoided as much as possible. Going back to the old ways is a better solution in this case.

As a useful addendum to this thread, I came across this article, which shows the way to convert flash drives from the default proprietary FAT32 format to a fully open UDF format. The required udftools program is available on SBo.

In addition to being a fully open standard, UDF can handle files larger than 4GB with ease. I might not need the capability now, but when I do, having it available to me is invaluable.

4 members found this post helpful.

Thanks mattallmill -- I'd not really heard of UDF apart from seeing it in passing so didn't realise it could be used for Windows. I'll definitely be playing with it now along with trying to find a decent cross-platform encryption solution. I've been using EXT file systems on my USB drives because of FAT's file size restrictions, patent FUD and general suckiness so it's good to know about UDF.

You're welcome. I thought it'd be good to let people know there are better solutions out there. I'm glad you enjoyed it!

I'm copying a 23.5GB file to my UDF formatted drive as I type -- it seems it will take an hour or so but if it works with my Windows XP and 8.1 VMs I'll be looking to use it for my backups.
Why, oh why can't manufacturers use this file system to get around MS patent FUD and file size restrictions? I still do not understand why Google haven't stomped all over FAT or why Tomtom decided to pay for FAT rather than use an alternative and tell MS to go away.

Microsoft isn't some itty-bitty company that Google can just stomp on, and FAT is so well-known that Microsoft can just demand a royalty for every flash drive sold. I think that's what's going on here. Microsoft needs all the cash infusion it can get, and FAT is one of several cash cows Microsoft can milk.

Just my 2 cents.

But here is an example of something that everyone from Tomtom to Google could have used -- so why not? I'm guessing that UDF isn't actually free but if I find it is I can only assume that Tomtom and Google have other reasons for paying Microsoft.

Well, I've read nothing that suggests UDF is anything other than free, but I am open to assertions to the contrary, backed by substantive proof, otherwise that's what I'm going with.

As for Tomtom and Google, my guess is that Microsoft is counting on the relative obscurity of UDF as a flash drive format to push its FAT32 regime. The general public has little idea what UDF is, but FAT and its ilk are well-known, and these companies are just on the bandwagon to help sell their products.

My pardon to the OP for potentially hijacking, but I think my question is in accord with the original theme of the thread.

Reaper, I'm about to install Slackware 14.1 on a 500GB Samsung EVO mSata for a laptop. I'm planning on doing as Richard suggested and specify "noatime" for the mount points in fstab. But I'd like to understand better what you are suggesting with the mknod command. Can you give a specific example to help me understand how you suggest using it? Thanks!