Message-ID: <alpine.LFD.2.00.1312091335440.2143@localhost.localdomain>
Date:	Mon, 9 Dec 2013 14:20:31 +0100 (CET)
From:	Lukáš Czerner <lczerner@...hat.com>
To:	"Theodore Ts'o" <tytso@....edu>
cc:	linux-ext4@...r.kernel.org
Subject: Re: Ext4 projects for 2014

On Sun, 8 Dec 2013, Theodore Ts'o wrote:

> Date: Sun, 8 Dec 2013 20:43:30 -0500
> From: Theodore Ts'o <tytso@....edu>
> To: linux-ext4@...r.kernel.org
> Subject: Ext4 projects for 2014
> 
> Unfortunately, I forgot my notes from our last conference call before
> heading off to the airport.  My fault for taking the notes on paper
> instead of electronically in the first place.  :-(
> 
> This is my best reconstruction of some of the ext4 projects for 2014.
> Please let me know if I've forgotten anything.
> 
> 1)  Support for Shingled (SMR) Drives
> 
> 2)  Data block compression -- Lukas

I think you meant data block checksums ?

I was thinking about this a little bit and the best way seems to be
to create a new checksum tree with pointers to extent tree and add
pointers from extent tree into the checksum tree.

Other possibility would not require any additional tree - checksum
would be sored directly in the blocks itself, with additional
information making data block self describing which would be great
for file system resilience, repair, misplaced writes and all sorts
of other failures. However this would make the file system with
checksum support unreadable by older version of the ext4.

I am interested to know what people thinks about that.

> 3)  reflink support --- Mingming
>        block-level snapshot support
>        Use case:  (a) VM guest images which are mostly derived from
>        	   	      the same common master image

I think this will be very useful functionality, however I think that
ext4 design is not really prepared for this kind of functionality
so we should be looking at how to enable this without actually
bending ext4 to do this on it's own.

The first idea I've had was to use device mapper for that. Simply
design a interface where we can tell block layer (DM) to create
snapshots from provided list of extents. That way we could use it
by other file system as well. However there might be some
shortcomings like for example the fact that DM thinp target is
operating of larger blocks of data (chunk size) then is the size of
the block.

We could always configure smaller chunk size for the thinp target
however that might be suboptimal as DM is not really designed for
fast and effective metadata processing since they usually do not
have that much metadata. But it's still a possibility with the
advantage to be generic solution for all file system and if the
major usecase for this would be databases or VM images (big files)
then the negatives of this approach might be negligible.


There is also other possibility. Alasdair mentioned to be that they
are planning to create deduplication target which should be fairly
easy to create. This might be very useful when implementing reflink
support for any file system. We would only need to pass down the tag
saying that we're writing duplicate data so the target does not
actually need to write anything.


> 
> 4)  Subvolume quotas (aka project quotas) -- Zheng
> 
> 5)  block improvements -- raid support / flash block size
> 
> 6)  Better support for non-rotating media
>        Differences between thinp and flash?
>        General problem: how do we measure improvements in the
>        block allocator?

This is obviously a big problem since the "improvement" is
inherently bound to "workload". So the main question might be what
"workload" do we test this on ?

Having a set of micro benchmarks each for different aspect of the
allocator might be useful, however in reality allocator will not
have ideal condition to make its decisions and often than not the real
workload is a combination of different things.

The other important thing when talking about testing block
allocator is to age the file system, because we really need to know
how well the allocator (or the file system itself) will do in the
long run, but just immediately after mkfs. This is especially true
for block allocation since its decisions are driven by the
fragmentation of the free space.

Thanks!
-Lukas

> 
> Other more minor todo items:
> 
> A)  Finish integration of inline support in e2fsprogs
> 
> B)  Dioread nolock cleanup
> 
> C)  Extent status tree shrinker
> 
> 
> 						- Ted
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists