Geert Uytterhoeven wrote:
I gave AxFS a try on PS3 (ppc64, always use big-endian 64-bit for testing new
code ;-).
When mounting the image, I got the crash below:
| attempt to access beyond end of device
| loop0: rw=0, want=4920, limit=4912
| Unable to handle kernel paging request for data at add
On Thursday 21 August 2008, Jared Hulbert wrote:
> 1) same mount point -
> I don't see how this works without an ioctl. I can't just make up
> files in my mounted filesystem. You expect the mounted version to
> match input to the mkfs. I'd not be happy with an ioctl. You can
> just read it.
>
On Friday 22 August 2008, Phillip Lougher wrote:
> 1. Support for > 4GB filesystems. In theory 2^64 bytes.
> 2. Compressed metadata
> 3. Inode timestamps
> 4. Hard-link support, and correct nlink counts
> 5. Sparse file support
> 6. Support for ". & ".." in readdir
> 7. Indexed directories for fas
On Friday 22 August 2008, Jared Hulbert wrote:
> > It certainly sounds like something for your medium-term TODO list,
> > although I wouldn't think of it as a show-stopper.
>
> Maybe. It more of a feature rather than a bug. It makes stat() and
> such fast. The trade off is RAM...
Yes. And if y
On Friday 22 August 2008, you wrote:
> You mean to take this off list?
No, i replied to your mail that was sent just to me.
Putting everyone back on now
> > In 3, you create files with sysfs_create_file, and are fairly limited
> > with how you can use it. A structured file like you have in procfs
Jamie Lokier wrote:
> Jared Hulbert wrote:
> > What kind of NOR you using? That is not what I measure with fast
> > synchronous burst NOR's.
>
> I think the "fast" in "fast synchronous" gives it away :-)
>
> I'm using Spansion MirrorBit S29GL128N, which reads at about 0.6 MByte/s.
By the way, w
Jared Hulbert wrote:
> On Fri, Aug 22, 2008 at 11:13 AM, Jamie Lokier <[EMAIL PROTECTED]> wrote:
> > Greg Ungerer wrote:
> >> One thing for sure is that many people who do non-MMU setups
> >> are interested in XIP to get the space savings. These are very
> >> often small devices with very constrain
On Fri, Aug 22, 2008 at 11:13 AM, Jamie Lokier <[EMAIL PROTECTED]> wrote:
> Greg Ungerer wrote:
>> One thing for sure is that many people who do non-MMU setups
>> are interested in XIP to get the space savings. These are very
>> often small devices with very constrained RAM and flash. (For
>> whate
Greg Ungerer wrote:
> One thing for sure is that many people who do non-MMU setups
> are interested in XIP to get the space savings. These are very
> often small devices with very constrained RAM and flash. (For
> whatever it is worth single NOR flash only boards are common in
> these smaller form
>> So do I understand right that 3 bytes is your minimum size, and going
>> smaller than that would not be helpful? Otherwise I would assume that
>> storing a '5' should only take one byte instead of three.
Right. But you need 3 bytes to store the maximum value 0x0a
If we had:
0x
Greg Ungerer wrote:
>
> Jamie Lokier wrote:
> >Jared Hulbert wrote:
> >>The biggest improvement is in the way AXFS allows for each page to be XIP
> >>or
> >>not. First, a user collects information about which pages are accessed
> >>on a
> >>compressed image for each mmap()ed region from /proc/a
> Elsewhere in this maze of threads Arnd claimed to have tested the
> benefits of metadata compression - and it making little impact.
>
> My guess is that it would make a large impact if metadata would be a
> significant part of the filesystem image. Usually metadata is close
> enough to 0% to be
On Fri, 22 August 2008 18:08:51 +0100, Phillip Lougher wrote:
>
> Squashfs stores significantly more metadata than cramfs. Remember
> cramfs has no support for filesystems > ~ 16Mbytes, no inode timestamps,
> truncates uid/gids, no hard-links, no nlink counts, no hashed
> directories, no uniq
> It certainly sounds like something for your medium-term TODO list,
> although I wouldn't think of it as a show-stopper.
Maybe. It more of a feature rather than a bug. It makes stat() and
such fast. The trade off is RAM...
--
To unsubscribe from this list: send the line "unsubscribe linux-embe
> Squashfs and AXFS should be seen as complementary filesystems, and there
> should be room in the Linux kernel for both.
Exactly. We had different design assumptions. One is not _better_
than the other, they are just different.
--
To unsubscribe from this list: send the line "unsubscribe linux-
> mismatch between documentation and implementation WRT the function name ;)
oops.
>>+{
>>+ struct axfs_super *sbi = AXFS_SB(sb);
>>+ u64 boffset = AXFS_FSOFFSET_2_DEVOFFSET(sbi, fsoffset);
>>+ u64 blocks;
>>+ u64 blksize = sb->s_blocksize;
>>+ unsigned long dst;
>>+
Arnd Bergmann wrote:
On Friday 22 August 2008, Jared Hulbert wrote:
This implies for block devices that the entire filesystem metadata has to be
cached in RAM. This severely limits the size of AXFS filesystems when using
block devices, or the else memory usage will be excessive.
This is where
Arnd Bergmann wrote:
On Friday 22 August 2008, Phillip Lougher wrote:
This looks very nice, but could use some comments about how the data is
actually stored on disk. It took me some time to figure out that it actually
allows to do tail merging into compressed blocks, which I was about to sugges
On Friday 22 August 2008, Jared Hulbert wrote:
> > This implies for block devices that the entire filesystem metadata has to be
> > cached in RAM. This severely limits the size of AXFS filesystems when using
> > block devices, or the else memory usage will be excessive.
>
> This is where 64bit sq
> The version in SVN seems to be slightly older than the one you submitted?
Oops. Okay I must have neglected to sync at the very end. Thanks.
I forgot, there is also a git repo at
git://git.infradead.org/users/jehulber/axfs.git
> Which platform(s) do you use for testing?
ARM, x86
> I gave A
On Friday 22 August 2008, Geert Uytterhoeven wrote:
> I gave AxFS a try on PS3 (ppc64, always use big-endian 64-bit for testing new
> code ;-).
> When mounting the image, I got the crash below:
>
> | attempt to access beyond end of device
> | loop0: rw=0, want=4920, limit=4912
> | Unable to handle
Hi Jared,
On Wed, 20 Aug 2008, Jared Hulbert wrote:
> I'd like to get a first round of review on my AXFS filesystem. This is a
> simple
> See http://axfs.sourceforge.net for more info.
The version in SVN seems to be slightly older than the one you submitted?
Which platform(s) do you u
Hi Jared,
When compiling mkfs.axfs from SourceForge SVN (tried ia32, amd64, ppc64), I
get:
cc -g -I./ -O0 -c -o mkfs.axfs.o mkfs.axfs.c
In file included from ./linux/axfs.h:32,
from mkfs.axfs.c:58:
/usr/include/linux/time.h:9: error: redefinition of ‘struct timespec’
/u
On Wed, Aug 20, 2008 at 10:45:47PM -0700, Jared Hulbert wrote:
>+/**
>+ *
>+ * axfs_copy_block_data
>+ *
>+ * Description: Helper function to read data from block device
>+ *
>+ * Parameters:
>+ *(IN) sb - pointer to su
On Wed, Aug 20, 2008 at 10:45:37PM -0700, Jared Hulbert wrote:
>+static int axfs_get_onmedia_super(struct super_block *sb)
>+{
>+ int err;
>+ struct axfs_super *sbi = AXFS_SB(sb);
>+ struct axfs_super_onmedia *sbo;
>+
>+ sbo = kmalloc(sizeof(*sbo), GFP_KERNEL);
>+ if (!sbo)
On Fri, 22 Aug 2008, Arnd Bergmann wrote:
> On Friday 22 August 2008, Jared Hulbert wrote:
> > If I have an array of u64 numbers tracking small numbers (a[0] = 1;
> > a[1] = 2;) just throwing that onmedia is a big waste.
> > (0x0001; 0x0002) Having different array types
> >
On Friday 22 August 2008, Jared Hulbert wrote:
> > This bytetable stuff looks overly complicated, both the data structure and
> > the access method. It seems like you are implementing your own custom
> > Huffman
> > compression with this.
> >
> > Is the reasonn for the bytetable just to pack numbe
On Friday 22 August 2008, Phillip Lougher wrote:
> >
> > This looks very nice, but could use some comments about how the data is
> > actually stored on disk. It took me some time to figure out that it actually
> > allows to do tail merging into compressed blocks, which I was about to
> > suggest
Jared Hulbert wrote:
The profiling code has certainly been useful to you during development,
and you should keep that code around for your own work on it,
but maybe you should not push that upstream, because regular users
are not going to need it.
Nope. Profiling is absolutely fundamental to h
> "Phillip" == Phillip Lougher <[EMAIL PROTECTED]> writes:
Hi,
Phillip> It only uses a relatively small subset of the VFS, and goes
Phillip> nowhere near the MTD subsystem. Recently dusting off an MTD
Phillip> patch I wrote for Squashfs a couple of years ago, I found it
Phillip> had to b
30 matches
Mail list logo
