Jan Kara | 1 Jun 11:44 2009
Picon

Re: [PATCH 03/11] vfs: Add better VFS support for page_mkwrite when blocksize < pagesize

On Sat 30-05-09 13:23:24, Pavel Machek wrote:
> Hi!
> 
> > On filesystems where blocksize < pagesize the situation is more complicated.
> > Think for example that blocksize = 1024, pagesize = 4096 and a process does:
> >   ftruncate(fd, 0);
> >   pwrite(fd, buf, 1024, 0);
> >   map = mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, fd, 0);
> >   map[0] = 'a';  ----> page_mkwrite() for index 0 is called
> >   ftruncate(fd, 10000); /* or even pwrite(fd, buf, 1, 10000) */
> >   fsync(fd); ----> writepage() for index 0 is called
> > 
> > At the moment page_mkwrite() is called, filesystem can allocate only one block
> > for the page because i_size == 1024. Otherwise it would create blocks beyond
> > i_size which is generally undesirable. But later at writepage() time, we would
> > like to have blocks allocated for the whole page (and in principle we have to
> > allocate them because user could have filled the page with data after the
> > second ftruncate()). This patch introduces a framework which allows filesystems
> > to handle this with a reasonable effort.
> 
> What happens when you do above sequence on today's kernels? Oops? 3000
> bytes of random junk in file? ...?
  Depends on the filesystem. For example on ext4, you'll see a WARN_ON and the data
won't be written. Some filesystems may just try to map blocks and possibly
hit deadlock or something like that. Filesystems like ext2 / ext3 /
reiserfs generally don't care because so far they allocate blocks on writepage
time (which has the problem that you can write data via mmap and kernel
will later discard them because it hits ENOSPC or quota limit). That's
actually what I was trying to fix originally.

(Continue reading)

Alexander Beregalov | 1 Jun 12:33 2009
Picon

SILO & Ext4

Hi

I found that Sparc cannot boot when rootfs is Ext4 (converted from ext3).

Is anyone working on adding ext4 support to silo?
Is it hard to implement?
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

David Miller | 1 Jun 12:41 2009
Picon

Re: SILO & Ext4

From: Alexander Beregalov <a.beregalov <at> gmail.com>
Date: Mon, 1 Jun 2009 14:33:02 +0400

> I found that Sparc cannot boot when rootfs is Ext4 (converted from ext3).
> 
> Is anyone working on adding ext4 support to silo?
> Is it hard to implement?

I'm personally not going to work on this, that's for sure :-)
Although it shouldn't be hard.

All of my effort has been spent on adding sparc support to
grub2.
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Alex Buell | 1 Jun 12:43 2009
X-Face
Picon

Re: SILO & Ext4

On Mon, 1 Jun 2009 14:33:02 +0400, I waved a wand and this message
magically appears in front of Alexander Beregalov:

> I found that Sparc cannot boot when rootfs is Ext4 (converted from
> ext3).

I simply have Silo boot from ext3 partition before mounting ext4
partition. Works well. 

> Is anyone working on adding ext4 support to silo?

Unknown - ask on the sparc linux mailing list.
--

-- 
http://www.munted.org.uk

Fearsome grindings.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Goswin von Brederlow | 1 Jun 13:33 2009
Picon

Re: [PATCH 03/11] vfs: Add better VFS support for page_mkwrite when blocksize < pagesize

Jan Kara <jack <at> suse.cz> writes:

> On Sat 30-05-09 13:23:24, Pavel Machek wrote:
>> Hi!
>> 
>> > On filesystems where blocksize < pagesize the situation is more complicated.
>> > Think for example that blocksize = 1024, pagesize = 4096 and a process does:
>> >   ftruncate(fd, 0);
>> >   pwrite(fd, buf, 1024, 0);
>> >   map = mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, fd, 0);
>> >   map[0] = 'a';  ----> page_mkwrite() for index 0 is called
>> >   ftruncate(fd, 10000); /* or even pwrite(fd, buf, 1, 10000) */
>> >   fsync(fd); ----> writepage() for index 0 is called
>> > 
>> > At the moment page_mkwrite() is called, filesystem can allocate only one block
>> > for the page because i_size == 1024. Otherwise it would create blocks beyond
>> > i_size which is generally undesirable. But later at writepage() time, we would
>> > like to have blocks allocated for the whole page (and in principle we have to
>> > allocate them because user could have filled the page with data after the
>> > second ftruncate()). This patch introduces a framework which allows filesystems
>> > to handle this with a reasonable effort.
>> 
>> What happens when you do above sequence on today's kernels? Oops? 3000
>> bytes of random junk in file? ...?
>   Depends on the filesystem. For example on ext4, you'll see a WARN_ON and the data
> won't be written. Some filesystems may just try to map blocks and possibly
> hit deadlock or something like that. Filesystems like ext2 / ext3 /
> reiserfs generally don't care because so far they allocate blocks on writepage
> time (which has the problem that you can write data via mmap and kernel
> will later discard them because it hits ENOSPC or quota limit). That's
(Continue reading)

Theodore Ts'o | 1 Jun 15:44 2009
Picon
Picon

64-bit e2fsprogs patch rebased against v1.41.6

I've taken the latest 64-bit e2fsprogs patch and rebased them against
v1.41.6.  While I was at it, I also fixed a number of bugs which showed
up when building e2fsprogs on a 32-bit platform and running "make
check".

The patches still need some cleanup before merging with mainline, but
the fact that they've been rebased against v1.41.6 and are now "make
check" clean is a good step forward.

The patch series for the work that I've done can be found here:

 	 git://github.com/tytso/e2fsprogs-64bit.git

... and if Nick or Val or any other ext4 developer anyone would like to
have commit access to the e2fsprogs 64-bit patch queue, just let me know.

I've also made the 64-bit e2fsprogs patches available on the "pu"
(proposed updates) branch of e2fsprogs.  As before, the "pu" branch may
be rewound and rebased without warning, so it's primarily useful for
people to easily get an update to the latest 64-bit patches.  For
collaborative development, it's best to use the e2fsprogs-64bit patch
queue.

I have *not* yet tested these patches on a 64-bit filesystem (mainly
because I'm not set up to easily do that testing at the moment), but it
has all of Nick and Val's patches, only rebased to 1.41.6, so hopefully
it should work.  If folks could try it out and send me feedback, I would
greatly appreciate it.

Thanks!!
(Continue reading)

Alex Buell | 1 Jun 15:53 2009
X-Face
Picon

Re: SILO & Ext4

On Mon, 01 Jun 2009 03:41:24 -0700 (PDT), I waved a wand and this
message magically appears in front of David Miller:

> All of my effort has been spent on adding sparc support to
> grub2.

That is wonderful news, can't wait to test it out in the near future!
--

-- 
http://www.munted.org.uk

Fearsome grindings.
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Jan Kara | 1 Jun 16:00 2009
Picon

Re: [PATCH 03/11] vfs: Add better VFS support for page_mkwrite when blocksize < pagesize

On Mon 01-06-09 13:33:08, Goswin von Brederlow wrote:
> Jan Kara <jack <at> suse.cz> writes:
> 
> > On Sat 30-05-09 13:23:24, Pavel Machek wrote:
> >> Hi!
> >> 
> >> > On filesystems where blocksize < pagesize the situation is more complicated.
> >> > Think for example that blocksize = 1024, pagesize = 4096 and a process does:
> >> >   ftruncate(fd, 0);
> >> >   pwrite(fd, buf, 1024, 0);
> >> >   map = mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, fd, 0);
> >> >   map[0] = 'a';  ----> page_mkwrite() for index 0 is called
> >> >   ftruncate(fd, 10000); /* or even pwrite(fd, buf, 1, 10000) */
> >> >   fsync(fd); ----> writepage() for index 0 is called
> >> > 
> >> > At the moment page_mkwrite() is called, filesystem can allocate only one block
> >> > for the page because i_size == 1024. Otherwise it would create blocks beyond
> >> > i_size which is generally undesirable. But later at writepage() time, we would
> >> > like to have blocks allocated for the whole page (and in principle we have to
> >> > allocate them because user could have filled the page with data after the
> >> > second ftruncate()). This patch introduces a framework which allows filesystems
> >> > to handle this with a reasonable effort.
> >> 
> >> What happens when you do above sequence on today's kernels? Oops? 3000
> >> bytes of random junk in file? ...?
> >   Depends on the filesystem. For example on ext4, you'll see a WARN_ON and the data
> > won't be written. Some filesystems may just try to map blocks and possibly
> > hit deadlock or something like that. Filesystems like ext2 / ext3 /
> > reiserfs generally don't care because so far they allocate blocks on writepage
> > time (which has the problem that you can write data via mmap and kernel
(Continue reading)

Goswin von Brederlow | 1 Jun 16:46 2009
Picon

Re: [PATCH 03/11] vfs: Add better VFS support for page_mkwrite when blocksize < pagesize

Jan Kara <jack <at> suse.cz> writes:

> On Mon 01-06-09 13:33:08, Goswin von Brederlow wrote:
>> Jan Kara <jack <at> suse.cz> writes:
>> 
>> > On Sat 30-05-09 13:23:24, Pavel Machek wrote:
>> >> Hi!
>> >> 
>> >> > On filesystems where blocksize < pagesize the situation is more complicated.
>> >> > Think for example that blocksize = 1024, pagesize = 4096 and a process does:
>> >> >   ftruncate(fd, 0);
>> >> >   pwrite(fd, buf, 1024, 0);
>> >> >   map = mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, fd, 0);
>> >> >   map[0] = 'a';  ----> page_mkwrite() for index 0 is called
>> >> >   ftruncate(fd, 10000); /* or even pwrite(fd, buf, 1, 10000) */
>> >> >   fsync(fd); ----> writepage() for index 0 is called
>> >> > 
>> >> > At the moment page_mkwrite() is called, filesystem can allocate only one block
>> >> > for the page because i_size == 1024. Otherwise it would create blocks beyond
>> >> > i_size which is generally undesirable. But later at writepage() time, we would
>> >> > like to have blocks allocated for the whole page (and in principle we have to
>> >> > allocate them because user could have filled the page with data after the
>> >> > second ftruncate()). This patch introduces a framework which allows filesystems
>> >> > to handle this with a reasonable effort.
>> >> 
>> >> What happens when you do above sequence on today's kernels? Oops? 3000
>> >> bytes of random junk in file? ...?
>> >   Depends on the filesystem. For example on ext4, you'll see a WARN_ON and the data
>> > won't be written. Some filesystems may just try to map blocks and possibly
>> > hit deadlock or something like that. Filesystems like ext2 / ext3 /
(Continue reading)

Jan Kara | 1 Jun 17:02 2009
Picon

Re: [PATCH 03/11] vfs: Add better VFS support for page_mkwrite when blocksize < pagesize

On Mon 01-06-09 16:46:28, Goswin von Brederlow wrote:
> Jan Kara <jack <at> suse.cz> writes:
> > On Mon 01-06-09 13:33:08, Goswin von Brederlow wrote:
> >> Jan Kara <jack <at> suse.cz> writes:
> >> 
> >> > On Sat 30-05-09 13:23:24, Pavel Machek wrote:
> >> >> Hi!
> >> >> 
> >> >> > On filesystems where blocksize < pagesize the situation is more complicated.
> >> >> > Think for example that blocksize = 1024, pagesize = 4096 and a process does:
> >> >> >   ftruncate(fd, 0);
> >> >> >   pwrite(fd, buf, 1024, 0);
> >> >> >   map = mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, fd, 0);
> >> >> >   map[0] = 'a';  ----> page_mkwrite() for index 0 is called
> >> >> >   ftruncate(fd, 10000); /* or even pwrite(fd, buf, 1, 10000) */
> >> >> >   fsync(fd); ----> writepage() for index 0 is called
> >> >> > 
> >> >> > At the moment page_mkwrite() is called, filesystem can allocate only one block
> >> >> > for the page because i_size == 1024. Otherwise it would create blocks beyond
> >> >> > i_size which is generally undesirable. But later at writepage() time, we would
> >> >> > like to have blocks allocated for the whole page (and in principle we have to
> >> >> > allocate them because user could have filled the page with data after the
> >> >> > second ftruncate()). This patch introduces a framework which allows filesystems
> >> >> > to handle this with a reasonable effort.
> >> >> 
> >> >> What happens when you do above sequence on today's kernels? Oops? 3000
> >> >> bytes of random junk in file? ...?
> >> >   Depends on the filesystem. For example on ext4, you'll see a WARN_ON and the data
> >> > won't be written. Some filesystems may just try to map blocks and possibly
> >> > hit deadlock or something like that. Filesystems like ext2 / ext3 /
(Continue reading)


Gmane