I think the term "virtual memory" in this context is just referring to the fact that this dialog allows you to view and change virtual memory related settings. In this case, you only have control over your paging file, so that's the only available setting. If there were other virtual memory knobs, I can imagine them placing those under the virtual memory dialog.
Oh, and I should add... if a device implements dynamic wear leveling, it needs to know something about the filesystem superimposed on it. If it's expecting FAT (because that's what it's programmed with at the factory), and it gets something else, that could explain the "random zeros" bugs people have posted about elsewhere on here.
I guess Sturgeon's Law applys to thumb drives too. (90% of everything is crud.)
Method doesn't work when improperly implemented. News at 11.
My point is that this seems to be more prevalent than people realize.
You're basically saying that wear-leveling is no panacea, because not all devices have a good wear-leveling algorithm. Wouldn't the solution, then, to be to demand devices which have a good algorithm, and to reward manufacturers who solve this problem with dollars and word of mouth?
The problem with short product lifecycles is that you might not realize you bought a turd until after it eats your data, and there's no time for word-of-mouth to spread. And with so many no-name USB sticks out there, how can you really tell which ones are the turds and which ones aren't? There really isn't a good feedback mechanism here. You have some hope paying high dollar for a name brand, but I wouldn't put too much stock in it.
Also, there are conflicting product goals: Dynamic wear leveling, as described in the PDF I linked above, gives faster write performance. Static wear leveling gives longer silicon lifetime. Which algorithm will generate better word of mouth? It's not clear, although I suspect faster write performance will generate better word-of-mouth while the product is still on store shelves.
Of course, the sad part is, the devices would probably be simpler, and cheaper to manufacture, if they didn't pretend to be block devices. Only problem is, then OSes (probably filesystems) would have to implement wear-leveling on their own, and Linux is the only one I know of which currently does that.
You would have to expose a number of low-level details, such as erase block size and other aspects of physical organization to the OS. And, you'd have to teach many OSes about how to talk to you, such as "block erase takes 5ms; device is unresponsive during erasure". Until there's a standardized way of doing this across platforms, faking yourself as a block device is an easy way to get broad compatibility with anything that understands the USB storage device (or SD card, or whatever format you're working with) profile.
Still, it would be nice if we could fix that problem in software, rather than letting manufacturers get it wrong.
You can still implement software wear leveling over the abstracted interface. Unless the device actively tries to work against you, it should help.
I'm not sure much gets logged on a properly functioning system with few services enabled. I just looked at my/var/log/messages on my Ubuntu system. It's pretty mind-numbingly boring:
Nov 30 07:53:25 metal syslogd 1.5.0#1ubuntu1: restart.
Nov 30 08:08:06 metal -- MARK --
Nov 30 08:28:06 metal -- MARK --
Nov 30 08:48:06 metal -- MARK --
Nov 30 09:08:06 metal -- MARK -- ... several more pages of the same...
Dec 4 07:08:06 metal -- MARK --
Dec 4 07:28:06 metal -- MARK --
Dec 4 07:48:06 metal -- MARK --
Dec 4 08:04:36 metal syslogd 1.5.0#1ubuntu1: restart.
Dec 4 08:28:07 metal -- MARK --
Dec 4 08:48:07 metal -- MARK --
That's one new write appending to the log every 20 minutes. I think by that point it's officially in the noise, even if it ends up being two writes (the second for updating the size and mtime in the inode).
As for/tmp, where does Fedora mount/tmp by default? I thought all the cool kids were using tmpfs these days. Of course, Ubuntu doesn't seem to for/tmp itself, but it does for some other transient filesystems:
$ mount | grep tmp
varrun on/var/run type tmpfs (rw,noexec,nosuid,nodev,mode=0755)
varlock on/var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=1777)
udev on/dev type tmpfs (rw,mode=0755)
devshm on/dev/shm type tmpfs (rw)
Apparently wear leveling is no panacea. Some devices wear-level only within a zone, and so a lot of activity in a hot zone can still burn that zone out. I guess such an algorithm only really works well when writes are distributed across zones evenly.
Unless the flash drives they are using are extremely lame (and I mean extremely), they use technology called wear leveling. This means that even if the journal is in a fixed location according to Linux, it's not in a fixed location according to the hard drive. Writes are spread to different bits of hardware for the same "physical" sector. As I understand it, every flash drive except for cheap, crappy USB drives use wear leveling (and even they might)
Apparently, the wear leveling isn't that great on some. Dave said he's seen an eee with dead flash precisely where the swap used to be. Apparently some of the lower-end flash devices wear-level in zones, meaning that if you have a particularly hot "zone", you could still burn that zone out. I imagine $10 USB sticks from Office Despot are going to have those lower-tech algorithms, or algorithms tweaked specifically for FAT filesystems.
This is not really that necessary anymore. Fedora 8 and on have relatime set by default which is only negligibly slower than noatime and there is no possibility of having any problems. You still can do it I suppose, but it's no where near the difference between atime and noatime
Dave Jones recently posted elsewhere his notes for improving things on the eee900. Several of the steps focus on getting proper performance out of the flash, and so would also apply to booting from a USB thumb drive or other flash media. Here's what he had to say:
Making the eee 900 series suck less.
Recently I've read about or spoken with a few people using Fedora on eeepc's who have been making some fairly big blunders without realising it. I've played with a few of these now, in their various incarnations.
The current one I've been carrying around is the 900 model
with a whopping 20GB of flash. It's quite deceptive, because there are actually two SSDs in there (one 4GB, and one 16GB)
These ssds are also pretty damn awful performance-wise compared to the newer generation of SSDs, but short of opening it up and retrofitting something, there's not much that can be done. The tips below should at least make it more bearable.
First off, don't use the default partitioning scheme.
By default, anaconda will choose to use lvm, and make a contiguous volume out of the two SSDs. This idea is fail, because the two disks aren't the same, and run at different speeds.
# hdparm -t/dev/sda
/dev/sda: Timing buffered disk reads: 108 MB in 3.04 seconds = 35.57 MB/sec
# hdparm -t/dev/sdb
/dev/sdb: Timing buffered disk reads: 86 MB in 3.05 seconds = 28.20 MB/sec
So, don't do that. Just create regular partitions, and make sure you put / on the faster of the two disks (the 4GB one), and leave the 16GB one for/home
Next, the default filesystem will be ext3. You really don't want this.
Given the journal is in a fixed location on disk, scribbling to it every time a file gets written is a great way to wear out the flash. Go with ext2. (Given that you've only got a few GB of flash anyway, a fsck doesn't take that long should you need to). Additionally, not having to write to the journal means that you're doing less IO, which is obviously a win when it's on such slow media.
This should go without saying - no swap.
Not only for the flash wear problem in the previous bullet, but also, because it's slow as all hell. If you find you run out of ram and get stuff oom-killed in this setup, well, you probably need to add more ram, or consider a real laptop.
After installing, change the fstab so that everything gets mounted with noatime.
Writes to the disk are just painful, so minimising them is the path to success here. It's doubtful that you'll be running anything on an eee that would actually care about atimes anyway.
With these points taken into consideration, the eee isn't a half-bad machine.
I still wouldn't want to be building kernels and such on it, but it's perfectly usable for email and such whilst travelling.
I imagine every kidnapper demanding a ransom is going to fully and professionally post process the images they send in to the media. Somehow, I doubt it.
Of course, this whole technique feels like a solution looking for a problem anyway.
You can use V to do visual highlight also, and just start typing:s/FROM/TO/g to do the replace. If you hit : followed by up arrow, you can go through previous commands you did on a visual-selected range. This makes repeating commands on multiple blocks easy.
Well... it's 10% faster than Chrome, not than Firefox 3. So, to use your analogy, it's like you're going down the road at 35MPH when Chrome blows by doing 80, and then Minefield blows past doing 88MPH.
Usually I won't set my cardboard aside either. My problem with paper is that it warps too easily from moisture from my hand. The cardboard is heavy enough I don't need to tape it, either.
I wonder how optical mice would work on etched glass? That could be a rather fashionable (if not entirely practical for all users) approach.
SunSpider is a Java benchmark? (Hint: Java != Javascript.) CA (the acronym referring to certificate authorities as a generic term) is a link to a quote for (the unrelated) CA, Inc.?
Ah well... hopefully Firefox 3.1 is as fast as they say.
I use the cardboard back off an old letter-size notepad. Larger, but thinner than a mousepad, and consequently more comfortable to use. And if it gets wrecked, I can just pitch it and get another. It's also easily set aside if I need the desk space for something.
This batch of disagree mail proves that people are now writing ridiculous emails just to get into disagree mail.
If so, then I want these peoples' crystal balls. The only Disagree Mail above that was written this year was written back in August. (All of them were written in August, but two of them were in August 2005, and one was August 2003. Only one was August 2008.)
Mental note: Use a key that gets distributed among several confederates and that I retain no personal knowledge of, other than a small piece. It will at least distribute the risk. Retain only a small portion of the key for myself, and store it in an obscure place.
No assumption made. Taco said this in the summary: "The next mail comes from a lady who doesn't mind clicking on things, in fact she loves it. If she had her way, everyone would have carpal tunnel syndrome." Maybe she should meet Mayor Quimby.
I can imagine allowing all transactions to be rounded to the nearest nickel at the cash register, even if they're by check or credit card. Where I was thinking you'd just leave things as they are are places where the transaction always lives entirely on a card, such as at the gas pump, or when ordering online and so on.
Slashdot Mirror
I think the term "virtual memory" in this context is just referring to the fact that this dialog allows you to view and change virtual memory related settings. In this case, you only have control over your paging file, so that's the only available setting. If there were other virtual memory knobs, I can imagine them placing those under the virtual memory dialog.
Oh, and I should add... if a device implements dynamic wear leveling, it needs to know something about the filesystem superimposed on it. If it's expecting FAT (because that's what it's programmed with at the factory), and it gets something else, that could explain the "random zeros" bugs people have posted about elsewhere on here.
I guess Sturgeon's Law applys to thumb drives too. (90% of everything is crud.)
My point is that this seems to be more prevalent than people realize.
The problem with short product lifecycles is that you might not realize you bought a turd until after it eats your data, and there's no time for word-of-mouth to spread. And with so many no-name USB sticks out there, how can you really tell which ones are the turds and which ones aren't? There really isn't a good feedback mechanism here. You have some hope paying high dollar for a name brand, but I wouldn't put too much stock in it.
Also, there are conflicting product goals: Dynamic wear leveling, as described in the PDF I linked above, gives faster write performance. Static wear leveling gives longer silicon lifetime. Which algorithm will generate better word of mouth? It's not clear, although I suspect faster write performance will generate better word-of-mouth while the product is still on store shelves.
You would have to expose a number of low-level details, such as erase block size and other aspects of physical organization to the OS. And, you'd have to teach many OSes about how to talk to you, such as "block erase takes 5ms; device is unresponsive during erasure". Until there's a standardized way of doing this across platforms, faking yourself as a block device is an easy way to get broad compatibility with anything that understands the USB storage device (or SD card, or whatever format you're working with) profile.
You can still implement software wear leveling over the abstracted interface. Unless the device actively tries to work against you, it should help.
I'm not sure much gets logged on a properly functioning system with few services enabled. I just looked at my /var/log/messages on my Ubuntu system. It's pretty mind-numbingly boring:
Nov 30 07:53:25 metal syslogd 1.5.0#1ubuntu1: restart.
... several more pages of the same ...
Nov 30 08:08:06 metal -- MARK --
Nov 30 08:28:06 metal -- MARK --
Nov 30 08:48:06 metal -- MARK --
Nov 30 09:08:06 metal -- MARK --
Dec 4 07:08:06 metal -- MARK --
Dec 4 07:28:06 metal -- MARK --
Dec 4 07:48:06 metal -- MARK --
Dec 4 08:04:36 metal syslogd 1.5.0#1ubuntu1: restart.
Dec 4 08:28:07 metal -- MARK --
Dec 4 08:48:07 metal -- MARK --
That's one new write appending to the log every 20 minutes. I think by that point it's officially in the noise, even if it ends up being two writes (the second for updating the size and mtime in the inode).
As for /tmp, where does Fedora mount /tmp by default? I thought all the cool kids were using tmpfs these days. Of course, Ubuntu doesn't seem to for /tmp itself, but it does for some other transient filesystems:
$ mount | grep tmp /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=0755) /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=1777) /dev type tmpfs (rw,mode=0755) /dev/shm type tmpfs (rw)
varrun on
varlock on
udev on
devshm on
Apparently wear leveling is no panacea. Some devices wear-level only within a zone, and so a lot of activity in a hot zone can still burn that zone out. I guess such an algorithm only really works well when writes are distributed across zones evenly.
See page 5 in this document for a description of zone-based wear leveling.
Apparently, the wear leveling isn't that great on some. Dave said he's seen an eee with dead flash precisely where the swap used to be. Apparently some of the lower-end flash devices wear-level in zones, meaning that if you have a particularly hot "zone", you could still burn that zone out. I imagine $10 USB sticks from Office Despot are going to have those lower-tech algorithms, or algorithms tweaked specifically for FAT filesystems.
According to Val Henson (who invented relatime, apparently):
So there you have it.
Dave Jones recently posted elsewhere his notes for improving things on the eee900. Several of the steps focus on getting proper performance out of the flash, and so would also apply to booting from a USB thumb drive or other flash media. Here's what he had to say:
I imagine every kidnapper demanding a ransom is going to fully and professionally post process the images they send in to the media. Somehow, I doubt it.
Of course, this whole technique feels like a solution looking for a problem anyway.
Sounds like Tyco blocks to me.
And if I had a ducat every time I'm reminded of that, I'd have at least MMXLIV.
What is this shampoo? Demand real poo instead!
You can use V to do visual highlight also, and just start typing :s/FROM/TO/g to do the replace. If you hit : followed by up arrow, you can go through previous commands you did on a visual-selected range. This makes repeating commands on multiple blocks easy.
Who named gNewSense anyway? I always read it as "Gee, nuisance." As much as I love Free Software, I think these guys are a bit tone deaf at times.
*sigh*
Well... it's 10% faster than Chrome, not than Firefox 3. So, to use your analogy, it's like you're going down the road at 35MPH when Chrome blows by doing 80, and then Minefield blows past doing 88MPH.
(Just better watch that flux capacitor...)
There are also particles (or rather, particle / anti-particle pairs) popping into and out of existence all the time. In fact, this is often invoked as the source of Hawking radiation.
--Joe
Usually I won't set my cardboard aside either. My problem with paper is that it warps too easily from moisture from my hand. The cardboard is heavy enough I don't need to tape it, either.
I wonder how optical mice would work on etched glass? That could be a rather fashionable (if not entirely practical for all users) approach.
SunSpider is a Java benchmark? (Hint: Java != Javascript.) CA (the acronym referring to certificate authorities as a generic term) is a link to a quote for (the unrelated) CA, Inc.?
Ah well... hopefully Firefox 3.1 is as fast as they say.
It wouldn't be too awful of an idea to use an accelerometer to help the optical sensor disambiguate on certain kinds of surfaces.
I use the cardboard back off an old letter-size notepad. Larger, but thinner than a mousepad, and consequently more comfortable to use. And if it gets wrecked, I can just pitch it and get another. It's also easily set aside if I need the desk space for something.
My S3 ViRGE sitting in my Gateway 2000 G6 Pentium II-300 weeps.
Ah, what the heck am I talking 'bout. I kicked that turd and its 4GB HD to the curb years ago.
If so, then I want these peoples' crystal balls. The only Disagree Mail above that was written this year was written back in August. (All of them were written in August, but two of them were in August 2005, and one was August 2003. Only one was August 2008.)
Mental note: Use a key that gets distributed among several confederates and that I retain no personal knowledge of, other than a small piece. It will at least distribute the risk. Retain only a small portion of the key for myself, and store it in an obscure place.
No assumption made. Taco said this in the summary: "The next mail comes from a lady who doesn't mind clicking on things, in fact she loves it. If she had her way, everyone would have carpal tunnel syndrome." Maybe she should meet Mayor Quimby.
I must say, the idea just isn't clicking with me.
I can imagine allowing all transactions to be rounded to the nearest nickel at the cash register, even if they're by check or credit card. Where I was thinking you'd just leave things as they are are places where the transaction always lives entirely on a card, such as at the gas pump, or when ordering online and so on.