On Sun 2009-06-28 19:33:02, Marco Stornelli wrote:
Pavel Machek wrote:
Ah now the write protection is a needed feature, in your previous
comment you talked about why not use ext2/3...
Marco
Just for your information I tried the same test with pc in a virtual
machine with 32MB
Ah now the write protection is a needed feature, in your previous
comment you talked about why not use ext2/3...
Marco
Just for your information I tried the same test with pc in a virtual
machine with 32MB of RAM:
Version 1.03e --Sequential Output--
Pavel Machek wrote:
Ah now the write protection is a needed feature, in your previous
comment you talked about why not use ext2/3...
Marco
Just for your information I tried the same test with pc in a virtual
machine with 32MB of RAM:
Version 1.03e --Sequential Output--
Pavel Machek wrote:
Ah now the write protection is a needed feature, in your previous
comment you talked about why not use ext2/3...
Marco
Just for your information I tried the same test with pc in a virtual
machine with 32MB of RAM:
Version 1.03e --Sequential Output--
If it loses power when doing atomic rename (to replace config files,
for example), it's likely that the whole /pramfs/configs/ directory
will be corrupt, because the rename is writing to the directory inode,
so you lose access to all names in that directory?
That sounds like it can't
Marco Stornelli wrote:
2009/6/24 Jamie Lokier ja...@shareable.org:
Marco wrote:
Second question: what happens if the system crashing _during_ a write
to a file. Does it mean that file will fail it's checksum when it's
read at the next boot?
Maybe files aren't so important. What
2009/6/24 Pavel Machek pa...@ucw.cz:
On Wed 2009-06-24 19:38:37, Marco wrote:
Pavel Machek wrote:
On Mon 2009-06-22 14:50:01, Tim Bird wrote:
Pavel Machek wrote:
block of fast non-volatile RAM that need to access data on it using a
standard filesytem interface.
Turns a block of fast
Pavel Machek wrote:
On Mon 2009-06-22 14:50:01, Tim Bird wrote:
Pavel Machek wrote:
block of fast non-volatile RAM that need to access data on it using a
standard filesytem interface.
Turns a block of fast RAM into 13MB/sec disk. Hmm. I believe you are
better with ext2.
Not if you want the
Marco wrote:
Second question: what happens if the system crashing _during_ a write
to a file. Does it mean that file will fail it's checksum when it's
read at the next boot?
Maybe files aren't so important. What about when you write a file,
and then rename it over an existing file
Pavel Machek wrote:
On Mon 2009-06-22 14:50:01, Tim Bird wrote:
Pavel Machek wrote:
block of fast non-volatile RAM that need to access data on it using a
standard filesytem interface.
Turns a block of fast RAM into 13MB/sec disk. Hmm. I believe you are
better with ext2.
Not if you want the
Pavel Machek wrote:
On Tue 2009-06-23 20:07:23, Marco wrote:
You are talked about journaling. This schema works well for a disk, but
what about a piece of ram? What about a crazy kernel that write in that
area for a bug? Do you remember for example the e1000e bug? It's not
I believe you
On Wed 2009-06-24 18:49:11, Marco wrote:
Pavel Machek wrote:
On Mon 2009-06-22 14:50:01, Tim Bird wrote:
Pavel Machek wrote:
block of fast non-volatile RAM that need to access data on it using a
standard filesytem interface.
Turns a block of fast RAM into 13MB/sec disk. Hmm. I believe
Pavel Machek wrote:
On Mon 2009-06-22 14:50:01, Tim Bird wrote:
Pavel Machek wrote:
block of fast non-volatile RAM that need to access data on it using a
standard filesytem interface.
Turns a block of fast RAM into 13MB/sec disk. Hmm. I believe you are
better with ext2.
Not if you want the
On Tue 2009-06-23 20:07:23, Marco wrote:
Pavel Machek wrote:
On Mon 2009-06-22 14:50:01, Tim Bird wrote:
Pavel Machek wrote:
block of fast non-volatile RAM that need to access data on it using a
standard filesytem interface.
Turns a block of fast RAM into 13MB/sec disk. Hmm. I believe
How do you handle hard-links, then?
Indeed hard-links are not supported :) Due to the design of this fs
there are some limitations explained in the documentation as not
hard-link, only private memory mapping and so on. However this
limitations don't limit the fs itself because you must
Pavel Machek wrote:
How do you handle hard-links, then?
Indeed hard-links are not supported :) Due to the design of this fs
there are some limitations explained in the documentation as not
hard-link, only private memory mapping and so on. However this
limitations don't limit the fs itself
On Mon 2009-06-22 10:31:28, Tim Bird wrote:
Pavel Machek wrote:
How do you handle hard-links, then?
Indeed hard-links are not supported :) Due to the design of this fs
there are some limitations explained in the documentation as not
hard-link, only private memory mapping and so on.
Pavel Machek wrote:
On Mon 2009-06-22 10:31:28, Tim Bird wrote:
Pavel Machek wrote:
How do you handle hard-links, then?
Indeed hard-links are not supported :) Due to the design of this fs
there are some limitations explained in the documentation as not
hard-link, only private memory mapping
Pavel Machek wrote:
On Mon 2009-06-22 10:31:28, Tim Bird wrote:
Pavel Machek wrote:
I did not see that in the changelog. If it is not general purpose
filesystem, it is lot less interesting.
PRAMFS is not a general purpose filesystem. Please read
the introductory post to this thread, or look
On Mon, 22 Jun 2009, Marco wrote:
I don't think, I think it's very clear:
In summary, PRAMFS is a light-weight, full-featured, and
space-efficient special filesystem that is ideal for systems with a
block of fast non-volatile RAM that need to access data on it using a
standard filesytem
On Mon 2009-06-22 20:07:06, Marco wrote:
Pavel Machek wrote:
On Mon 2009-06-22 10:31:28, Tim Bird wrote:
Pavel Machek wrote:
How do you handle hard-links, then?
Indeed hard-links are not supported :) Due to the design of this fs
there are some limitations explained in the documentation
On Mon 2009-06-22 11:55:04, Tim Bird wrote:
Pavel Machek wrote:
On Mon 2009-06-22 10:31:28, Tim Bird wrote:
Pavel Machek wrote:
I did not see that in the changelog. If it is not general purpose
filesystem, it is lot less interesting.
PRAMFS is not a general purpose filesystem. Please
On Mon 2009-06-22 14:50:01, Tim Bird wrote:
Pavel Machek wrote:
block of fast non-volatile RAM that need to access data on it using a
standard filesytem interface.
Turns a block of fast RAM into 13MB/sec disk. Hmm. I believe you are
better with ext2.
Not if you want the RAM-based
On Mon 2009-06-22 23:57:53, Pavel Machek wrote:
On Mon 2009-06-22 14:50:01, Tim Bird wrote:
Pavel Machek wrote:
block of fast non-volatile RAM that need to access data on it using a
standard filesytem interface.
Turns a block of fast RAM into 13MB/sec disk. Hmm. I believe you are
Why is an entire filesystem needed, instead of simply a block driver
if the ramdisk driver cannot be used?
From documentation:
A relatively straight-forward solution is to write a simple block
driver for the non-volatile RAM, and mount over it any disk-based
filesystem such as
Pavel Machek wrote:
Why is an entire filesystem needed, instead of simply a block driver
if the ramdisk driver cannot be used?
From documentation:
A relatively straight-forward solution is to write a simple block
driver for the non-volatile RAM, and mount over it any disk-based
filesystem
1. Disk-based filesystems such as ext2/ext3 were designed for optimum
performance on spinning disk media, so they implement features such
as block groups, which attempts to group inode data into a contiguous
set of data blocks to minimize disk seeking when accessing files. For
2009/6/17 Chris Friesen cfrie...@nortel.com:
Marco wrote:
This is a second attempt at mainlining Pramfs. The first attempt was
back in early 2004 by MontaVista. Since then the kernel code has almost
been completely rewritten. So my first item on the list was porting the
code on a recent
Marco wrote:
There's the checksum, but the most important feature of this fs is the
write protection. The page table entries that map the
backing-store RAM are normally marked read-only. Write operations into
the filesystem temporarily mark the affected pages as writeable, the
write operation
Marco wrote:
To enable direct
I/O at all times for all regular files requires either that
applications be modified to include the O_DIRECT flag on all file
opens, or that a new filesystem be used that always performs direct
I/O by default.
This could be done as well by
Bryan Henderson wrote:
Marco wrote:
To enable direct
I/O at all times for all regular files requires either that
applications be modified to include the O_DIRECT flag on all file
opens, or that a new filesystem be used that always performs direct
I/O by default.
This could be
Tim Bird wrote:
Marco wrote:
This is a second attempt at mainlining Pramfs. The first attempt was
back in early 2004 by MontaVista. Since then the kernel code has almost
been completely rewritten. So my first item on the list was porting the
code on a recent kernel version. After that I added
Marco wrote:
To enable direct
I/O at all times for all regular files requires either that
applications be modified to include the O_DIRECT flag on all file
opens, or that a new filesystem be used that always performs direct
I/O by default.
This could be done as well by just
Marco wrote:
Simply because the ramdisk was not designed to work in a persistent
environment.
One thing with persistent RAM disks is you _really_ want it to be
robust if the system crashes for any reason while it is being
modified. The last thing you want is to reboot, and find various
On Sat, 2009-06-13 at 15:20 +0200, Marco wrote:
Are there any pending patents on this code?
NO, there aren't patents pending on this code. MontaVista had a pending
patent application but now it has abandoned this way. Daniel Walker can
confirm that.
Confirmed , there are no patents on this
35 matches
Mail list logo
