inode cache question
When does an inode enter, and leave the inode cache? (ie. at what VFS entry points) I am interested in keeping inode data either in the inode cache, OR the backing store, but not both. Regards, Jeff -- Jeff Garzik | Just once, I wish we would encounter Building 1024| an alien menace that wasn't immune to MandrakeSoft, Inc. | bullets. -- The Brigadier, "Dr. Who"
Re: Race in buffer code (Was Re: move block #A to block #B on a given device.)
On Fri, 5 Nov 1999, Mikulas Patocka wrote:
BTW. neither getblk nor mark_buffer_uptodate check for i/o completion.
That was exactly what I wanted to point out :).
Isn't it race? Many filesystem do it this way.
All depends on the semantics you want I think. It doesn't seems black and
white to me.
Note that for example in 2.3.25 with shared mappings you can't avoid
userspace to not change the mapped memory while at the same time a
peripheral is reading it in DMA. This is by design.
But the shared mapped region is only data, while if the buffer you are
over-writing is _valid_ metadata (likely to be metadata otherwise you
wouldn't play with the buffer cache in first place) then you probably like
to know that if your machine will reboot -f, there will be at least an old
_valid_ snapshot of metadata in such block.
So maybe you want a wait_on_buffer() before the memcpy if the buffer you
are going to write to was previously valid.
What if user does cat /dev/hda1/dev/null on mounted device while
filesystem driver does getblk? ... the buffer gets corrupted.
User: Filesystem driver:
open("/dev/hda1", O_RDONLY);
read();
waiting for io completion...
getblk();
mark_buffer_uptodate();
write_some_data_there
read data is stored, end_request()
BOOM! changes are lost.
There is another - more severe - destruction case: breada. On filesystems
that use breada it can smash buffers randomly!
Mikulas Patocka
Re: Race in buffer code (Was Re: move block #A to block #B on agiven device.)
On Fri, 5 Nov 1999, Mikulas Patocka wrote: What if user does cat /dev/hda1/dev/null on mounted device while filesystem driver does getblk? ... the buffer gets corrupted. I was considering the case where the buffer returned by getblk is _just_ uptodate. If the block is just uptodate then all potential readers as us won't even try to start read-io and so the `cp /dev/? /dev/null` won't trigger any I/O and won't risk to invalidate our memcpy. Andrea
i_blocksize, long long i_size and conversion size to blocks
Hi, I just downloaded 2.3.26-pre2 - and surprise, ncpfs does not compile. It happens because of there is inode-i_blocks = (inode-i_size - 1) / inode-i_blksize + 1; Should I introduce i_blksize_shift into private portion of inode and maintain i_blksize only for other kernel parts (stat syscall) or what is correct action? I can hardcode shift value into code because of block size on ncpfs is always 512 bytes, but I just want to know... Thanks, Petr Vandrovec [EMAIL PROTECTED] P.S.: I'm not subscribed to linux-fsdevel (yet), so please CC me if you are replying on fsdevel only.
