All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Jan Kara <jack@suse.cz>
Cc: Fabian Frederick <fabf@skynet.be>,
	Andrew Morton <akpm@linux-foundation.org>,
	Alexey Khoroshilov <khoroshilov@ispras.ru>,
	Ian Campbell <ian.campbell@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>,
	Evgeniy Dushistov <dushistov@mail.ru>,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 1/2 linux-next] Revert "ufs: fix deadlocks introduced by sb mutex merge"
Date: Tue, 23 Jun 2015 22:56:41 +0100	[thread overview]
Message-ID: <20150623215641.GR17109@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20150623164608.GR2427@quack.suse.cz>

On Tue, Jun 23, 2015 at 06:46:08PM +0200, Jan Kara wrote:

> Looks good to me. BTW also ext4 (with BIGALLOC feature) and OCFS2 can have
> block allocation unit (called cluster) larger than page size. However the
> block size of both filesystems is still <= page size. So at least ext4
> handles fun with partially initialized clusters by just marking parts
> of the cluster as uninitialized in the extent tree. But the code is still
> pretty messy to be honest.

Well, with UFS there's no place on disk to store such "this block is
uninitialized" marks - it uses a bog-standard Unix inode structure.

There are two units - fragments and blocks.  Block is an aligned group
of adjacent fragments; normal ratio is 8:1.  Block is at least 4Kb
(and always a power of two), fragment is at least a one sector and
block:fragment ratio is at most 8:1.  Inode structure is normal for a Unix
filesystem (12 direct + indirect + double indirect + triple indirect).
Each reference covers a block worth of file offsets and almost all
of them point to full blocks.  Indirects are full blocks as well.
Reference to a block is represented as the number of the first fragment
in it (i.e. with normal parameters bits 0..2 are clear).  Block bitmap is
actually a fragment bitmap (i.e. bit per fragment).  The only situation
when a reference is *not* to a full block is the last reference in a
file shorter than 12*block size (i.e. not requiring indirects at all).
In that case the last direct reference points to less than a full block
(unless the size in fragments is a multiple of block:fragment ratio,
that is).  One unusual thing is that holes can't extend to EOF - the last
byte *must* be allocated.  (BTW, the only difference between UFS2 and
UFS1 in that area is that fragment numbers are 64bit now.  There had been
talk about turning block:fragment ratio into a per-inode value, but so far
nobody has implemented that - ->di_blksize is there, but it's never used).

  parent reply	other threads:[~2015-06-23 21:56 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1432754131-27425-1-git-send-email-fabf@skynet.be>
     [not found] ` <20150527145735.e3d1913bc66426038d53be32@linux-foundation.org>
2015-06-04  5:01   ` [PATCH 1/2 linux-next] Revert "ufs: fix deadlocks introduced by sb mutex merge" Al Viro
2015-06-04 22:22     ` Al Viro
2015-06-04 22:22     ` Al Viro
2015-06-05 16:27     ` Fabian Frederick
2015-06-05 18:50       ` Al Viro
2015-06-05 22:03         ` Al Viro
2015-06-17  8:57           ` Jan Kara
2015-06-17  8:57           ` Jan Kara
2015-06-17 20:31             ` Al Viro
2015-06-17 20:31             ` Al Viro
2015-06-19 23:07               ` Al Viro
2015-06-19 23:07               ` Al Viro
2015-06-23 16:46                 ` Jan Kara
2015-06-23 16:46                 ` Jan Kara
2015-06-23 21:56                   ` Al Viro
2015-06-23 21:56                   ` Al Viro [this message]
2015-06-05 22:03         ` Al Viro
2015-06-06  8:04         ` Fabian Frederick

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=20150623215641.GR17109@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=akpm@linux-foundation.org \
    --cc=dushistov@mail.ru \
    --cc=fabf@skynet.be \
    --cc=ian.campbell@citrix.com \
    --cc=jack@suse.cz \
    --cc=khoroshilov@ispras.ru \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=roger.pau@citrix.com \
    --cc=xen-devel@lists.xen.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.