The patch titled
ext4: use simple_prepare_write to zero page data
has been added to the -mm tree. Its filename is
ext4-use-simple_prepare_write-to-zero-page-data.patch
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See
On Mon, 9 April 2007 12:21:15 -0500, Eric Sandeen wrote:
Phillip Susi wrote:
When the filesystem is told to mount the disk read only, that means it
should not write to it.
It means the filesystem should not be writeable when it is mounted.
This is not the same as saying that the
This is work in progress
Changes from from my previous patches are as follows:
a) Mark the file system unclean if we fail migrating
b) support for migrating more than one file
c) Support for migrating all the ext3 inode in the file system
d) Fix the free block counts. ( Make sure fsck pass
From: Aneesh Kumar K.V [EMAIL PROTECTED]
The code is derived out of the latest ext4 kernel source. I
have tried to keep the code as close as possible to the kernel
sources. This makes sure that any fixes for the tree building
code in kernel should be easily applied to ext4migrate. The
ext3_ext
From: Aneesh Kumar K.V [EMAIL PROTECTED]
Add ext4migrate utility that helps in migrating a ext3 block mapped
inode to ext4 extent mapped inode.
ext4migrate command takes the below syntax
ext4migrate --display | --migrate image_name [filename]
The --display option helps in displaying the block
On Tue, Apr 10, 2007 at 09:22:53AM +0200, Jörn Engel wrote:
Under all conditions it should be safe to mount a read-only block
device, but that is not the same as mounting a filesystem read-only.
In particular, it is a lame excuse when this claim is true. If the
block-device is read-only,
On Tue, 10 April 2007 07:27:18 -0400, Theodore Tso wrote:
I suppose what you could do is to read in the journal, and use it to
create an remapping table so that when you want to read block #5126,
and block number 5126 is in the journal, to read the journal version
of the block instead of the
We have some of the material reviewed and posted now from the IO FS
workshop.
USENIX has posted the talks at:
http://www.usenix.org/events/lsf07/tech/tech.html
A write up of the workshop went out at LWN and invoked a healthy discussion:
http://lwn.net/Articles/226351/
At that LWN
On Wed, 2007-04-04 at 12:52 -0400, John Anthony Kazos Jr. wrote:
According to Documentation/filesystems/Locking, -get_sb() is called
with the BKL held, but looking through the code, I'm not able to find
where it is being taken.
I noticed that too. Unless I'm just dumb and can't see it,
On Tue, 2007-04-10 at 12:03 -0400, Ming Zhang wrote:
On Wed, 2007-04-04 at 12:52 -0400, John Anthony Kazos Jr. wrote:
According to Documentation/filesystems/Locking, -get_sb() is called
with the BKL held, but looking through the code, I'm not able to find
where it is being taken.
I
On Tue, Apr 10, 2007 at 02:08:26PM +0200, Jörn Engel wrote:
On Tue, 10 April 2007 07:27:18 -0400, Theodore Tso wrote:
I suppose what you could do is to read in the journal, and use it to
create an remapping table so that when you want to read block #5126,
and block number 5126 is in the
Eric Sandeen wrote:
It means the filesystem should not be writeable when it is mounted.
This is not the same as saying that the filesystem itself should do no
IO in the course of making that read-only mount available.
I disagree.
I respectfully disagree, see above.
Based on what? I argue
Eric Sandeen wrote:
except in the case of a journaling filesystem, where the journal in
theory obviates the need for a fsck. (yes, I know... fsck still has a
place...) But, fsck is largely meaningless until the journal has been
recovered anyway (fs can only be consistent if it includes
Ted,
Another small bug I think: if the root directory contains shared
blocks, e2fsck pass1c search_dirent_proc() will be looking for
one more containing directory than it will ever find, and thus
loses an opportunity to terminate early.
Signed-off-by: Jim Garlick [EMAIL PROTECTED]
Index:
Since it is possible for the same block device to be mounted multiple
times concurrently by the same filesystem, and since ext3 explicitly
disables the BKL during its fill_super operation which would prevent this,
what is the result of mounting it multiple times this way? Especially if
the
On Apr 10, 2007 20:49 -0400, John Anthony Kazos Jr. wrote:
Since it is possible for the same block device to be mounted multiple
times concurrently by the same filesystem, and since ext3 explicitly
disables the BKL during its fill_super operation which would prevent this,
what is the
16 matches
Mail list logo
