Displaying 20 results from an estimated 400 matches similar to: "[PATCH 1/3] ocfs2: Optimize inode allocation by remembering last group."
2009 Feb 26
3
[PATCH 0/3] ocfs2-1.4: Backport inode alloc from mainline.
Hi all,
this patch set are the backport of inode alloc improvement from
mainline to ocfs2-1.4.
the patches are almost the same excpet one thing:
Joel has added JBD2 support to ocfs2, so he has added "max_blocks" to
alloc_context and add a new function
"ocfs2_reserve_clusters_with_limit". We don't have that in ocfs2-1.4. So
there are some great difference in patch 2.
2009 Jan 15
5
[PATCH 0/3] ocfs2: Inode Allocation Strategy Improvement.v2
Changelog from V1 to V2:
1. Modify some codes according to Mark's advice.
2. Attach some test statistics in the commit log of patch 3 and in
this e-mail also. See below.
Hi all,
In ocfs2, when we create a fresh file system and create inodes in it,
they are contiguous and good for readdir+stat. While if we delete all
the inodes and created again, the new inodes will get spread out and
that
2009 Apr 17
26
OCFS2 1.4: Patches backported from mainline
Please review the list of patches being applied to the ocfs2 1.4 tree.
All patches list the mainline commit hash.
Thanks
Sunil
2008 Sep 04
4
[PATCH 0/3] ocfs2: Switch over to JBD2.
ocfs2 currently uses the Journaled Block Device (JBD) for its
journaling. This is a very stable and tested codebase. However, JBD
is limited by architecture to 32bit block numbers. This means an ocfs2
filesystem is limited to 2^32 blocks. With a 4K blocksize, that's 16TB.
People want larger volumes.
Fortunately, there is now JBD2. JBD2 adds 64bit block number support
and some other
2009 Mar 17
33
[git patches] Ocfs2 updates for 2.6.30
Hi,
The following patches comprise the bulk of Ocfs2 updates for the
2.6.30 merge window. Aside from larger, more involved fixes, we're adding
the following features, which I will describe in the order their patches are
mailed.
Sunil's exported some more state to our debugfs files, and
consolidated some other aspects of our debugfs infrastructure. This will
further aid us in debugging
2013 Feb 21
1
[PATCH] the ac->ac_allow_chain_relink=0 won't disable group relink
From: "Xiaowei.Hu" <xiaowei.hu at oracle.com>
ocfs2_block_group_alloc_discontig() disables chain relink by setting
ac->ac_allow_chain_relink = 0 because it grabs clusters from multiple
cluster groups. It doesn't keep the credits for all chain relink,but
ocfs2_claim_suballoc_bits overrides this in this call trace:
2009 Mar 18
2
[RFC] metadata alloc fix in machines which has PAGE_SIZE > CLUSTER_SIZE
Hi Mark/Joel,
I meet with some meta allocation bugs when I implement reflink these
days. And after some investigation, I think we should have the same
problem when we have PAGE_SIZE > CLUSTER_SIZE. So I create a scenario
today in one ppc box and try. the box panic as I expected. ;)
The scenario is that: Create a file with the disk layout like this(with
bs=512, and cs=4K).
debugfs: stat
2010 Jul 11
2
[PATCH 1/2] JBD2: Allow feature checks before journal recovery
Before we start accessing a huge (> 16 TiB) OCFS2 volume, we need to
confirm that its journal supports 64-bit offsets. So we need to check
the journal's feature bits before recovering the journal.
This is not possible with JBD2 at present, because the journal
superblock (where the feature bits reside) is not loaded from disk until
the journal is recovered.
This patch loads the journal
2008 Apr 02
10
[PATCH 0/62] Ocfs2 updates for 2.6.26-rc1
The following series of patches comprises the bulk of our outstanding
changes for Ocfs2.
Aside from the usual set of cleanups and fixes that were inappropriate for
2.6.25, there are a few highlights:
The '/sys/o2cb' directory has been moved to '/sys/fs/o2cb'. The new location
meshes better with modern sysfs layout. A symbolic link has been placed in
the old location so as to
2006 Aug 15
0
[git patches] ocfs2 updates
This set of patches includes a few dlm related fixes from Kurt, and a small,
trivial cleanup by Adrian.
Also included are three disk allocation patches by me - two fixes and one
incremental improvement in our allocation strategy. These have been around
since early June, so I think they've had enough testing that they can go
upstream.
Please pull from 'upstream-linus' branch of
2009 Mar 27
42
[PATCH 00/42] ocfs2: Add reflink file support. V1
Hi all,
So I have finally finished the v1 of reflink for ocfs2. It has some
bugs that I am still investigating, but the schema is almost there. So
I'd like to send it out first for review. And Tristan and I will
continue to work on the stability of the code.
The general information for reflink, please see
http://oss.oracle.com/osswiki/OCFS2/DesignDocs/Reflink.
For the design doc, please
2009 Apr 03
42
[PATCH 00/42] ocfs2: Add reflink file support. V2
Hi all,
Change from v1 to v2: bug fix and metadata/credits reservation
improvement.
The general information for reflink, please see
http://oss.oracle.com/osswiki/OCFS2/DesignDocs/Reflink.
For the design doc, please see
http://oss.oracle.com/osswiki/OCFS2/DesignDocs/RefcountTrees
http://oss.oracle.com/osswiki/OCFS2/DesignDocs/ReflinkOperation
2011 Sep 05
0
Slow performance
Hello again,
We have hit some performance problem today in one of our clusters. The
performance suddenly drop from the normal performance (about
30Mbytes/s), read/write, to a few Kbytes/s (about 200Kbytes/s), read
only, for a while, and as sudden as it started, it backs to the normal
read/write performance, cycling randomly. When the "read only" occurs
on one node, the other shows only
2023 Mar 29
1
ChaCha20 Rekey Frequency
I was wondering if there was something specific to the internal chacha20
cipher as opposed to OpenSSL implementation.
I can't just change the block size because it breaks compatibility. I
can do something like as a hack (though it would probably be better to
do it with the compat function):
if (strstr(enc->name, "chacha"))
*max_blocks = (u_int64_t)1 << (16*2);
2023 Mar 29
2
ChaCha20 Rekey Frequency
On Wed, 29 Mar 2023, Chris Rapier wrote:
> I was wondering if there was something specific to the internal chacha20
> cipher as opposed to OpenSSL implementation.
>
> I can't just change the block size because it breaks compatibility. I can do
> something like as a hack (though it would probably be better to do it with the
> compat function):
>
> if
2023 Mar 29
1
[EXTERNAL] Re: ChaCha20 Rekey Frequency
I'm hardly an expert on this, but if I remember correctly, the rekey rate for good security is mostly dependent on the cipher block size. I left my reference books at home; so, I can't come up with a reference for you, but I would take Chris' "I'm deeply unsure of what impact that would have on the security of the cipher" comment seriously and switch to a cipher with a
2023 Mar 29
1
[EXTERNAL] Re: ChaCha20 Rekey Frequency
That's true for block ciphers, but ChaCha20+poly1305 is a stream cipher.
On Wed, 29 Mar 2023, Robinson, Herbie wrote:
>
> I?m hardly an expert on this, but if I remember correctly, the rekey rate
> for good security is mostly dependent on the cipher block size.? I left my
> reference books at home; so, I can?t come up with a reference for you, but I
> would take Chris?
2010 Jul 22
4
[PATCH 1/3] ext3/ext4: Factor out disk addressability check
As part of adding support for OCFS2 to mount huge volumes, we need to
check that the sector_t and page cache of the system are capable of
addressing the entire volume.
An identical check already appears in ext3 and ext4. This patch moves
the addressability check into its own function in fs/libfs.c and
modifies ext3 and ext4 to invoke it.
Signed-off-by: Patrick LoPresti <lopresti at
2009 Feb 13
44
[PATCH 0/40] ocfs2: Detach ocfs2 metadata I/O from struct inode
The following series of patches attempts to detach metadata I/O from
struct inode. They are currently tied together pretty tightly.
Metadata reads happen via the ocfs2_read_blocks() functions, writes via
both jbd2 and ocfs2_write_blocks().
- Each inode has a cache of associated metadata blocks stored on its
ip_metadata_cache member. The ocfs2_read/write_blocks() functions
take a struct
2023 Mar 24
1
ChaCha20 Rekey Frequency
I'm wondering why the ChaCha20 cipher rekeys so frequently. At speed I'm
seeing rekeys every second or two. So I'm spending a large amount of
time in the rekey process. From what I've read about ChaCha20 it
shouldn't need to be rekeyed quite so frequently. Am I missing something
obvious?
Just curious more than anything else.
Chris