| Amir G. | Re: [PATCH 4/8] e2fsprogs: Next3 snapshot control with c ...
On Mon, Jun 21, 2010 at 9:17 PM, Andreas Dilger
I must show you the beauty of the 'S','n','a','p','s','h','o','t'
flags, because I grew very fond of them.
Here is a list of 4 snapshots for example:
Snapshots list:
id inode attributes disk-usage mtime filename
---------------------------------------------
44 277994 Snap--o- 7.3M Jun 14 16:50 /var/vol/2/.ctera/snapshots/4
43 277993 S--psh-- 12.0K Jun 14 16:50 /var/vol/2/.ctera/snapshots/3
42 277992 ----sh-- 0 Jun 14 16:50 ...
| Jun 22, 1:56 am 2010 |
| Amir G. |
| Jun 22, 2:06 am 2010 |
| Hsuan-Ting | Re: E2fsprogs master branch now has all 64-bit patch applied
Sounds like I must enable 64-bit feature when mkfs.
Then it will work, right?
But base on my test, it will occur core dump when resize:
(gdb) bt
#0 0x00000000004160bf in ext2fs_test_bit64 ()
#1 0x0000000000416318 in ba_test_bmap ()
#2 0x0000000000410629 in ext2fs_test_generic_bmap ()
#3 0x0000000000410656 in ext2fs_test_block_bitmap_range2 ()
#4 0x000000000040873d in ext2fs_get_free_blocks2 ()
#5 0x000000000040936d in ext2fs_allocate_group_table ()
#6 0x0000000000404456 in ...
| Jun 22, 2:15 am 2010 |
| Amir G. |
| Jun 22, 2:47 am 2010 |
| Amir Goldstein | Next3 on-disk format change request
Hi Ted,
As you may have read, Next3 release 1.0.11 automatically migrates to
new on-disk format.
(see http://next3.sf.net)
Also, I would like to ask you again to promote Next3/Ext4 merge as a
topic on LSF,
if you think it is an appropriate topic.
My on-disk format change request is to re-assign a ro_compat feature
for IS_SNAPSHOT (currently in s_flags).
The reason for this request is the following scenario, which was
posted on next3-users list:
"If I use dd to restore a full ...
| Jun 22, 3:30 am 2010 |
| Jan Kara | Re: Updated ext4 quota design document
Hi,
It might be reasonable to checksum dquots so that we get closer to
all-metadata-are-checksummed state. I'm just thinking whether checksumming
each dquot is so useful. For example OCFS2 checksums each quota block. That
has an advantage that also quota file tree blocks and headers are
protected. Also it's possible to use the generic block checksumming
framework in JBD2 for this case. OTOH ext4 seems to have chosen to checksum
each group descriptor individually so checksumming each dquot ...
| Jun 22, 7:20 am 2010 |
| Andreas Dilger | Re: E2fsprogs master branch now has all 64-bit patch applied
On 2010-06-22, at 03:15, Hsuan-Ting wrote:
Yes, that you can't just set this flag on an existing filesystem and expect it to work. The only possibility to do this is to have resize2fs move the inode tables in groups where there are group descriptor tables (as if it were growing the filesystem) and then write 64-byte group descriptors.
Cheers, Andreas
--
| Jun 22, 9:17 am 2010 |
| Andrew Morton |
| Jun 22, 12:35 pm 2010 |
| tytso | Re: Updated ext4 quota design document
Well, the reason why I suggested just checksuming the each quota entry
is that it was the simplest thing to do, and wouldn't require making
huge changes to the rest of the quota_tree code. It also means we
don't need to do any kind of special locking to make sure there isn't
another process modifying another quota entry in the same block at the
same time that we are calculating the per-block checksum --- i.e.,
I assume OCFS2 is just using dqdh_pad2 or dqdh_pad1 for its checksum?
...
| Jun 22, 1:08 pm 2010 |
| Jan Kara | Re: Updated ext4 quota design document
With metadata which get journaled it should be quite easy. JBD already
must know before you go and modify buffer contents - that's why
journal_get_write_access and friends exist. It also makes sure that your
data cannot be modified from the moment the buffer enters commit upto the
moment the commit is finished. So you can use buffer commit hook to compute
No. quota_tree code sets info->dqi_usable_bs to something smaller than
1 << info->dqi_qtree_depth. Thus quota code leaves a few bytes in ...
| Jun 22, 1:29 pm 2010 |
| Jeff Moyer | [PATCH 0/3 v5][RFC] ext3/4: enhance fsync performance wh ...
Hi,
Running iozone with the fsync flag, or fs_mark, the performance of CFQ is
far worse than that of deadline for enterprise class storage when dealing
with file sizes of 8MB or less. I used the following command line as a
representative test case:
fs_mark -S 1 -D 10000 -N 100000 -d /mnt/test/fs_mark -s 65536 -t 1 -w 4096 -F
When run using the deadline I/O scheduler, an average of the first 5 numbers
will give you 448.4 files / second. CFQ will yield only 106.7. With
this patch series ...
| Jun 22, 2:34 pm 2010 |
| Jeff Moyer | [PATCH 1/3] block: Implement a blk_yield function to vol ...
This patch implements a blk_yield to allow a process to voluntarily
give up its I/O scheduler time slice. This is desirable for those processes
which know that they will be blocked on I/O from another process, such as
the file system journal thread. Following patches will put calls to blk_yield
into jbd and jbd2.
Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
---
block/blk-core.c | 13 +++++
block/blk-settings.c | 6 ++
block/cfq-iosched.c | 123 ...
| Jun 22, 2:35 pm 2010 |
| tytso |
| Jun 22, 2:52 pm 2010 |
| Andreas Dilger | problems with large group descriptors and 64bit
I was just looking through the 64-bit patches that have landed on master, and I see some obvious bugs with the handling of large group descriptors. In particular, there are some places that still assume they know the group descriptor size, even in the "opaque" routines added by Eric in commit efe0b401465a3ee836180614b5b435acbb84fc27.
lib/ext2fs/open.c assumes ext2_group_desc in a couple of places, instead of calling ext2fs_group_desc() to get the right offset:
#ifdef WORDS_BIGENDIAN
...
| Jun 22, 4:24 pm 2010 |
