From: Paul A. <pal...@ea...> - 2004-03-02 17:59:09
|
One of our developers has been porting fuse (and OWFS) to embedded systems. As you can see from his note, the hard-coded 4096 byte block size is a problem. Some potential fixes: 1. Detect it from the linux kernel source code. 2. configure switch 3. module parameter Paul Alfille -----Forwarded Message----- > From: Christian Magnusson <chr...@ru...> > To: owf...@li... > Cc: pal...@ea..., 'Christian Magnusson' <chr...@ru...> > Subject: [Owfs-developers] owfs for embedded systems > Date: Tue, 02 Mar 2004 13:01:03 +0100 > > > Hi Paul! > > You can find some tar-files on my web-server http://home.mag.cx/uclinux/mag/ > > All files are just packed from uClinux-dist/user/mag/ and there are some > diff-files that shows the code-changes. > > If the files should be compiled to another embedded system (I have a > MCF5206eC3 evaluation board), you should take a closer look at the makefile > at fuse-1.1/kernel/Makefile. The CFLAGS are set manually to create the > fuse-module since I didn't now how to create it automatically from > uClinux-dist/linux-2.4.x/. > > The biggest problem were caused by fuse which hardcode the block-size to > 4096 bytes. I think many embedded systems have a smaller blocksize since the > flash and ram-disks are pretty small. > > I don't know how to make it easy for other users to configure, compile and > use, but I guess this could help someone. > > /Christian > > > > > -----Original Message----- > From: owf...@li... > [mailto:owf...@li...] On Behalf Of Paul > Alfille > Sent: den 28 februari 2004 07:07 > To: owfs-developers > Subject: Re: [Owfs-developers] ow_cache.c bug in owfs-0.99p0RC.tar.gz > > Christian, I'm very pleased you attempted this! It's been a dream to > implement OWFS in an embedded system. Can you write up what you've done > so I can put it in the project page? > > > > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > _______________________________________________ > Owfs-developers mailing list > Owf...@li... > https://lists.sourceforge.net/lists/listinfo/owfs-developers |
From: <Mik...@et...> - 2004-03-03 08:22:45
|
> One of our developers has been porting fuse (and OWFS) to embedded > systems. As you can see from his note, the hard-coded 4096 byte > block size is a problem. Some potential fixes: > > [...] > > > The biggest problem were caused by fuse which hardcode the > > block-size to 4096 bytes. I think many embedded systems have a > > smaller blocksize since the flash and ram-disks are pretty small. There may be a misunderstanding here: block size is the property of a disk filesystem, it's the size of the chunks in which data is stored. Block size can be anything from 512 to infinity, e.g. ext2 has a 1024 byte and a 4096 byte variant. FUSE is _not_ a disk filesystem, so there isn't any block size. The 4096 bytes in FUSE is the page size (it is actually more than 4096 on some architecutres I think). The page size determines what chunks of data are read from or written to the filesystem, but I don't see why an embedded system should behave differently in this respect. What am I missing? Miklos -- At the end of this message, my employer might have automatically inserted a stupid disclaimer. This nonsense is out of my control and should simply be ignored. This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. |
From: Christian M. <chr...@ru...> - 2004-03-03 12:00:56
|
Hmmm... After Miklos Szeredi's reply I tried to remove the changes I made to PAGE_CACHE_SIZE in fuse-1.1/kernel/dir.c and restored the fuse-1-1/lib/fuse.c where I replaced _dummy=4096. For some reason it worked without those patches now, so I'm a bit confused why I had problem with it from the beginning... I'm sure I had lots of problems with reading files before my patches. It always tried to read 4096 bytes and I got errors on all operations from the beginning. Nevermind, I guess the only problems are: fuse-1.1/kernel/file.c +#ifdef KERNEL_2_6 if(file->f_mode & FMODE_WRITE) filemap_fdatawrite(inode->i_mapping); +#endif Replacement of fork() in fuse-1.1/lib/mount.c and fuse-1.1/util/fusermount.c fuse-1.1/util/fusermount.c: fixes to make it possible to use with uClibc. /Christian -----Original Message----- From: Paul Alfille [mailto:pal...@ea...] Sent: den 2 mars 2004 19:03 To: fuse-list Cc: chr...@ru... Subject: [Fwd: [Owfs-developers] owfs for embedded systems] One of our developers has been porting fuse (and OWFS) to embedded systems. As you can see from his note, the hard-coded 4096 byte block size is a problem. Some potential fixes: 1. Detect it from the linux kernel source code. 2. configure switch 3. module parameter Paul Alfille |
From: <Mik...@et...> - 2004-03-03 12:25:31
|
> After Miklos Szeredi's reply I tried to remove the changes I made to > PAGE_CACHE_SIZE in fuse-1.1/kernel/dir.c and restored the > fuse-1-1/lib/fuse.c where I replaced _dummy=4096. That _dummy is not even used anywhere, it's the remainder of some old compatibility thing. > Nevermind, I guess the only problems are: fuse-1.1/kernel/file.c > +#ifdef KERNEL_2_6 > if(file->f_mode & FMODE_WRITE) > filemap_fdatawrite(inode->i_mapping); > +#endif filemap_fdatawrite is actually defined as filemap_fdatasync on 2.4 at the top of kernel/file.c. Maybe filemap_fdatasync doesn't exist on earlier 2.4 kernels. What is your kernel version? > fuse-1.1/util/fusermount.c: fixes to make it possible to use with uClibc. I'll try to integrate these into fusermount. Thanks, Miklos -- At the end of this message, my employer might have automatically inserted a stupid disclaimer. This nonsense is out of my control and should simply be ignored. This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. |
From: Christian M. <chr...@ru...> - 2004-03-03 12:33:36
|
It's not exported from kernel/ksyms.c in uclinux latest linux-2.4.24-uc0 when NO_MM is defined for some reason. #ifndef NO_MM EXPORT_SYMBOL(filemap_fdatasync) #endif /Christian -----Original Message----- From: Miklos Szeredi [mailto:Mik...@et...] Sent: den 3 mars 2004 13:20 To: chr...@ru... Cc: avf...@li...; pal...@ea... Subject: Re: [Avf-fuse-dev] RE: [Fwd: [Owfs-developers] owfs for embedded systems] > After Miklos Szeredi's reply I tried to remove the changes I made to > PAGE_CACHE_SIZE in fuse-1.1/kernel/dir.c and restored the > fuse-1-1/lib/fuse.c where I replaced _dummy=4096. That _dummy is not even used anywhere, it's the remainder of some old compatibility thing. > Nevermind, I guess the only problems are: fuse-1.1/kernel/file.c > +#ifdef KERNEL_2_6 > if(file->f_mode & FMODE_WRITE) > filemap_fdatawrite(inode->i_mapping); > +#endif filemap_fdatawrite is actually defined as filemap_fdatasync on 2.4 at the top of kernel/file.c. Maybe filemap_fdatasync doesn't exist on earlier 2.4 kernels. What is your kernel version? > fuse-1.1/util/fusermount.c: fixes to make it possible to use with uClibc. I'll try to integrate these into fusermount. Thanks, Miklos -- At the end of this message, my employer might have automatically inserted a stupid disclaimer. This nonsense is out of my control and should simply be ignored. This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. |
From: <Mik...@et...> - 2004-03-03 12:53:04
|
> It's not exported from kernel/ksyms.c in uclinux latest linux-2.4.24-uc0 > when NO_MM is defined for some reason. > > #ifndef NO_MM > EXPORT_SYMBOL(filemap_fdatasync) > #endif That explains it. Thanks, Miklos -- At the end of this message, my employer might have automatically inserted a stupid disclaimer. This nonsense is out of my control and should simply be ignored. This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. |