Hi Guys. What would be the advantages of using tmpfs over mfs as memory file system? Say I want to mount my /tmp as tmpfs instead of mfs, would that be a good thing to do? Or I would like to rather mount a file systems on a LiveCD or my embedded device as tmpfs instead of mfs, would that also have any impact on the system ? Cheers Marcin.
On Mon, Oct 03, 2005 at 10:54:50AM +0200, Marcin Jessa wrote: > Hi Guys. > > What would be the advantages of using tmpfs over mfs as memory file > system? > Say I want to mount my /tmp as tmpfs instead of mfs, would that be a > good thing to do? > Or I would like to rather mount a file systems on a LiveCD or my > embedded device as tmpfs instead of mfs, would that also have any impact > on the system ? I didn't try it yet, but its design goals were to be more efficient and use less memory than MFS (which uses UFS's data structures). -- -- Manuel Bouyer <bouyer <at> antioche.eu.org> NetBSD: 26 ans d'experience feront toujours la difference --
Marcin Jessa wrote:
> What would be the advantages of using tmpfs over mfs as memory file
> system?
> Say I want to mount my /tmp as tmpfs instead of mfs, would that be a
> good thing to do?
> Or I would like to rather mount a file systems on a LiveCD or my
> embedded device as tmpfs instead of mfs, would that also have any impact
> on the system ?
I just tried a couple of tests on -current i386 that was pretty much
"vmstat ; mount_foo ; <command> ; vmstat ; unmount ; vmstat"
for the following commands:
- sh MAKEDEV all (lots of devices)
mfs used 1264 kB or 316 pages (df said 33 kB used)
tmpfs used 308 kB or 77 pages (df said 308 kB used)
- extract some etexts from a tar file (a few big files)
mfs used 20776 kB or 5194 pages (df said 9379 kB used)
tmpfs used 9108 kB or 2277 pages (df said 9108 kB used)
- extract some pkgsrc directories from a tar file (lots of little files)
mfs used 79292 kB or 19823 pages (df said 24991 kB used)
tmpfs used 54060 kB or 13515 pages (df said 54060 kB used)
(Continue reading)
Simon Burge wrote:
> I just tried a couple of tests on -current i386 that was pretty much
>
> "vmstat ; mount_foo ; <command> ; vmstat ; unmount ; vmstat"
>
> for the following commands:
Someone asked for timing info as well. Here's the best time of three
runs for each test:
- sh MAKEDEV all (lots of devices)
mfs used 1264 kB or 316 pages (df said 33 kB used)
tmpfs used 308 kB or 77 pages (df said 308 kB used)
mfs: 3.426u 4.668s 0:07.76 104.1% 0+0k 36+3977io 0pf+0w
tmpfs: 3.255u 4.341s 0:07.13 106.4% 0+0k 0+1io 0pf+0w
- extract some etexts from a tar file (a few big files)
mfs used 20776 kB or 5194 pages (df said 9379 kB used)
tmpfs used 9108 kB or 2277 pages (df said 9108 kB used)
mfs: 0.557u 0.309s 0:00.99 85.8% 0+0k 3+2566io 0pf+0w
tmpfs: 0.619u 0.144s 0:00.76 98.6% 0+0k 0+0io 0pf+0w
- extract some pkgsrc directories from a tar file (lots of little files)
mfs used 79292 kB or 19823 pages (df said 24991 kB used)
(Continue reading)
Marcin Jessa <lists <at> yazzy.org> writes: > What would be the advantages of using tmpfs over mfs as memory file > system? Others have mentioned part of this, but let me mention something others have not: if you sometimes need a big /tmp but mostly you don't, tmpfs can win because it can allocate and free memory easily. mfs cannot -- it is one fixed size (though it is pageable.) The other thing folks haven't mentioned: in theory at least (I don't know if this is broken at the moment), mmaps of tmpfs don't allocate new pages. That can be a big win in an embedded context. Perry
Hello everyone, I'm a third-year computer science student at Nottingham University, UK. I'm about to start my final dissertation and am interested in researching operating systems wrt embedded devices. I have noticed that a 'flash translation layer' was suggested as part of the Google Summer of Code project but wasn't taken up as a project. I'd be interested in this and would be more than willing to spend the time on it. If anyone could offer me some pointers (or a mentorship!) or let me know if it was decided that this wasn't needed, had already been done, etc then it would be much appreciated! Thanks, Alex -- -- Alex Allan School of Computer Science University of Nottingham aja03u <at> cs.nott.ac.uk 07812 129823
Alex Allan <alex.allan <at> urn1350.net> writes: > I'm a third-year computer science student at Nottingham University, > UK. I'm about to start my final dissertation and am interested in > researching operating systems wrt embedded devices. > > I have noticed that a 'flash translation layer' was suggested as part > of the Google Summer of Code project but wasn't taken up as a project. > > I'd be interested in this and would be more than willing to spend the > time on it. > > If anyone could offer me some pointers (or a mentorship!) or let me > know if it was decided that this wasn't needed, had already been done, > etc then it would be much appreciated! I haven't looked at the web page for SoC, but the general problem is to produce a set of drivers so that a chunk of flash memory can be used effectively as a disk. As I recall, the primary issue is wear leveling. There are, however, lots of references on the net for wear leveling algorithms and you should be able to implement one pretty easily. You might also want to study how the Linux stuff works, if only to get ideas for the interface, and check (I haven't in a while) whether there is code to do any of this stuff in FreeBSD or OpenBSD that might be of use. In theory, one could produce a new file system specifically geared to the needs of flash memory, and that might be a lot more efficient than(Continue reading)
On Tue, 4 Oct 2005 20:13:25 +0100 Alex Allan <alex.allan <at> urn1350.net> wrote: : Hello everyone, Hi Alex. : I'm a third-year computer science student at Nottingham University, UK. : I'm about to start my final dissertation and am interested in : researching operating systems wrt embedded devices. : : I have noticed that a 'flash translation layer' was suggested as part : of the Google Summer of Code project but wasn't taken up as a project. Just out of couriousity, what is a "flash translation layer" ? : I'd be interested in this and would be more than willing to spend the : time on it. : : If anyone could offer me some pointers (or a mentorship!) or let me : know if it was decided that this wasn't needed, had already been done, : etc then it would be much appreciated! : : Thanks, : : Alex : : -- : Alex Allan : School of Computer Science(Continue reading)
On 4-Oct-05, at 1:43 PM, Perry E. Metzger wrote: >> If anyone could offer me some pointers (or a mentorship!) or let me >> know if it was decided that this wasn't needed, had already been >> done, >> etc then it would be much appreciated! > > I haven't looked at the web page for SoC, but the general problem is > to produce a set of drivers so that a chunk of flash memory can be > used effectively as a disk. As I recall, the primary issue is wear > leveling. There are, however, lots of references on the net for wear > leveling algorithms and you should be able to implement one pretty > easily. > > You might also want to study how the Linux stuff works, if only to get > ideas for the interface, and check (I haven't in a while) whether > there is code to do any of this stuff in FreeBSD or OpenBSD that might > be of use. > > In theory, one could produce a new file system specifically geared to > the needs of flash memory, and that might be a lot more efficient than > a wear leveling adaptation layer, but that is a much more ambitious > project and I would try the simpler one first. I have the misfortune of having experience with the Linux Flash 'stuff'. You want to look at 'mtd' (memory technology device) for the flash driver, and 'jffs2' which is the filesystem layer that is commonly used over top of an mtd partition. Quick example:(Continue reading)
On 4 Oct 2005, at 20:45, Marcin Jessa wrote: > Just out of couriousity, what is a "flash translation layer" ? I probably should've taken this from the SoC website: Flash translation layer (top) Implement flash-translation layer to handle bad-block management/wear leveling such that a FFS filesystem could be placed on above NAND flash chip. Contact(s): [tech-embed] http://www.netbsd.org/contrib/projects.html Alex -- -- Alex Allan School of Computer Science University of Nottingham aja03u <at> cs.nott.ac.uk 07812 129823
RSS Feed1 | |
|---|---|
6 | |
1 | |
1 | |
2 | |
1 | |
7 | |
2 | |
1 | |
2 | |
5 | |
1 | |
17 | |
4 | |
3 | |
4 | |
1 | |
13 | |
5 | |
1 | |
7 | |
8 | |
1 | |
24 | |
8 | |
16 | |
55 | |
5 | |
19 | |
39 | |
14 | |
4 | |
6 | |
6 | |
1 | |
1 | |
3 | |
22 | |
12 | |
28 | |
7 | |
12 | |
14 | |
12 | |
23 | |
63 | |
9 | |
11 | |
32 | |
46 | |
1 | |
46 | |
43 | |
17 | |
15 | |
4 | |
28 | |
2 | |
24 | |
8 | |
2 | |
8 | |
7 | |
21 | |
5 | |
9 | |
5 | |
1 | |
5 | |
4 | |
15 | |
10 | |
10 | |
8 | |
19 | |
11 | |
2 | |
6 | |
4 | |
10 | |
4 | |
13 | |
4 | |
44 |
