linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Anton Altaparmakov <aia21@cam.ac.uk>
To: Jan Koss <kossjan@gmail.com>
Cc: kernelnewbies@nl.linux.org, linux-fsdevel@vger.kernel.org
Subject: Re: fragmentation && blocks "realloc"
Date: Sat, 21 Jan 2006 20:28:37 +0000 (GMT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0601212022390.29190@hermes-2.csi.cam.ac.uk> (raw)
In-Reply-To: <b97d23040601210142u73f57cefx2e685be5b95ec486@mail.gmail.com>

On Sat, 21 Jan 2006, Jan Koss wrote:
> >It will all just work
> >fine.  (Unless you have omitted to say things about your fs that are
> >important.  Why don't you show all your code rather than just those
> >snippets and then proper advice can be given...)
> 
> fs is just a simple analog of ufs/ext2/minix/sysv. It is block

All of the above a page cache users, not block device oriented at all.

> oriented, and I suppose that working with pages, instead of blocks
> make it more complicated, then it should to be.

It also makes it very slow not to use the page cache...

> >You do not want the invalidate_inode_buffers() call.  It makes no sense
> 
> Great, we reached the point.
> Yes, my file system based on usage sb_bread/brelse.

Right, so nothing like the other file systems you compare yourself to 
then.  None of them are sb_bread/brelse based.

> As ordinary file system my file system implements readpage and writepage,
> it is similar to
> static int sysv_writepage(struct page *page, struct writeback_control *wbc)
> {
> 	return block_write_full_page(page,get_block,wbc);
> }
> static int sysv_readpage(struct file *file, struct page *page)
> {
> 	return block_read_full_page(page,get_block);
> }
> 
> get_block make such thing
> map_bh(...)

Err, so you are page cache based and not sb_bread/brelse based at all.

I think you are confused...  (-;

> So, when we "realloc" blocks, what happen with these "old" mapped (or
> used in some other way) blocks?
> 
> How can I prevent usage "old" blocks instead of "new" blocks?
> Or if I mark old and new blocks as dirty all will be right?

You cannot do the reallocation using your method if the above page cache 
functions are used like that by your fs.  You need to do it how I showed 
it to you first, i.e. without sb_bread/brelse as those make no sense 
whatsoever for you.  (They access the block device directly, completely 
bypassing the page cache so you are breaking cache coherency and are 100% 
broken by design.)

You seem to be extremely conused I am afraid.  They only way to help you 
is to see your whole file system code unless you start becoming clearer 
about what you are really doing so that you don't keep making 
contradictory statements in two successive sentences...

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

  reply	other threads:[~2006-01-21 20:28 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-20 11:47 fragmentation && blocks "realloc" Jan Koss
2006-01-20 13:34 ` Anton Altaparmakov
2006-01-20 15:46   ` Jan Koss
2006-01-20 19:22     ` Jan Koss
2006-01-20 20:11       ` Anton Altaparmakov
2006-01-21  9:42         ` Jan Koss
2006-01-21 20:28           ` Anton Altaparmakov [this message]
2006-01-22 20:58             ` Jan Koss
2006-01-22 21:32               ` Anton Altaparmakov
2006-01-22 22:05                 ` Jan Koss
2006-01-24 10:37                   ` Anton Altaparmakov
2006-02-23 21:47                     ` Nate Diller
2006-01-20 20:04     ` Anton Altaparmakov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0601212022390.29190@hermes-2.csi.cam.ac.uk \
    --to=aia21@cam.ac.uk \
    --cc=kernelnewbies@nl.linux.org \
    --cc=kossjan@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).