belese porno izleyin
Belese porno kanallarini izlemek icin http://www.turk-tv.com sayfasini ziyaret edin :-)
Re: reiser4-2.6.18-rc2-mm1: possible circular locking dependency detected in txn_end
On Tuesday 01 August 2006 01:29, Laurent Riffard wrote:
> Le 31.07.2006 21:55, Vladimir V. Saveliev a écrit :
> > Hello
> >
> > What kind of load did you run on reiser4 at that time?
>
> I just formatted a new 2GB Reiser4 FS, then I moved a whole ccache
> cache tree to this new FS (cache size was about 20~30 Mbytes).
> Something like:
>
> # mkfs.reiser4 /dev/vglinux1/ccache
> # mount -tauto -onoatime /dev/vglinux1/ccache /mnt/disk
> # mv ~laurent/.ccache/* /mnt/disk/
I was not able to reproduce it. Can you please try the following patch?
lock validator friendly locking of new atom in
atom_begin_and_assign_to_txnh and locking of two atoms.
Signed-off-by: Alexander Zarochentsev <[EMAIL PROTECTED]>
---
fs/reiser4/txnmgr.c | 14 --
fs/reiser4/txnmgr.h | 15 +++
2 files changed, 23 insertions(+), 6 deletions(-)
Index: linux-2.6-git/fs/reiser4/txnmgr.c
===
--- linux-2.6-git.orig/fs/reiser4/txnmgr.c
+++ linux-2.6-git/fs/reiser4/txnmgr.c
@@ -730,10 +730,12 @@ static int atom_begin_and_assign_to_txnh
assert("jmacd-17", atom_isclean(atom));
/*
-* do not use spin_lock_atom because we have broken lock ordering here
-* which is ok, as long as @atom is new and inaccessible for others.
+* lock ordering is broken here. It is ok, as long as @atom is new
+* and inaccessible for others. We can't use spin_lock_atom or
+* spin_lock(&atom->alock) because they care about locking
+* dependencies. spin_trylock_lock doesn't.
*/
- spin_lock(&(atom->alock));
+ check_me("", spin_trylock_atom(atom));
/* add atom to the end of transaction manager's list of atoms */
list_add_tail(&atom->atom_link, &mgr->atoms_list);
@@ -749,7 +751,7 @@ static int atom_begin_and_assign_to_txnh
atom->super = reiser4_get_current_sb();
capture_assign_txnh_nolock(atom, txnh);
- spin_unlock(&(atom->alock));
+ spin_unlock_atom(atom);
spin_unlock_txnh(txnh);
return -E_REPEAT;
@@ -2791,10 +2793,10 @@ static void lock_two_atoms(txn_atom * on
/* lock the atom with lesser address first */
if (one < two) {
spin_lock_atom(one);
- spin_lock_atom(two);
+ spin_lock_atom_nested(two);
} else {
spin_lock_atom(two);
- spin_lock_atom(one);
+ spin_lock_atom_nested(one);
}
}
Index: linux-2.6-git/fs/reiser4/txnmgr.h
===
--- linux-2.6-git.orig/fs/reiser4/txnmgr.h
+++ linux-2.6-git/fs/reiser4/txnmgr.h
@@ -502,6 +502,7 @@ static inline void spin_lock_atom(txn_at
{
/* check that spinlocks of lower priorities are not held */
assert("", (LOCK_CNT_NIL(spin_locked_txnh) &&
+ LOCK_CNT_NIL(spin_locked_atom) &&
LOCK_CNT_NIL(spin_locked_jnode) &&
LOCK_CNT_NIL(spin_locked_zlock) &&
LOCK_CNT_NIL(rw_locked_dk) &&
@@ -513,6 +514,20 @@ static inline void spin_lock_atom(txn_at
LOCK_CNT_INC(spin_locked);
}
+static inline void spin_lock_atom_nested(txn_atom *atom)
+{
+ assert("", (LOCK_CNT_NIL(spin_locked_txnh) &&
+ LOCK_CNT_NIL(spin_locked_jnode) &&
+ LOCK_CNT_NIL(spin_locked_zlock) &&
+ LOCK_CNT_NIL(rw_locked_dk) &&
+ LOCK_CNT_NIL(rw_locked_tree)));
+
+ spin_lock_nested(&(atom->alock), SINGLE_DEPTH_NESTING);
+
+ LOCK_CNT_INC(spin_locked_atom);
+ LOCK_CNT_INC(spin_locked);
+}
+
static inline int spin_trylock_atom(txn_atom *atom)
{
if (spin_trylock(&(atom->alock))) {
Re: Solaris ZFS on Linux
On 8/2/06, Krzysztof Halasa <[EMAIL PROTECTED]> wrote: Kyle Moffett <[EMAIL PROTECTED]> writes: > IMHO the best alternative for a situation like that is a storage > controller with a battery-backed cache and a hunk of flash NVRAM for > when the power shuts off (just in case you run out of battery), as > well as a separate 1GB battery-backed PCI ramdisk for an external > journal device (likewise equipped with flash NVRAM). It doesn't take > much power at all to write a gig of stuff to a small flash chip > (Think about your digital camera which runs off a couple AA's), so > with a fair-sized on-board battery pack you could easily transfer its > data to NVRAM and still have power left to back up data in RAM for 12 > hours or so. That way bootup is fast (no reading 1GB of data from > NVRAM) but there's no risk of data loss. Not sure - reading flash is fast, but writing is quite slow. A digital camera can consume a set of 2 or 4 2500 mAh AA cells for a fraction of 1 GB (of course, only a part of power goes to flash). Seeks are fast, throughput is terrible, power is minimal: http://techreport.com/reviews/2006q3/supertalent-flashide/index.x?pg=1 Wil
Re: new reiser4 patch for linux-2.6.16 is available, upgrade from reiser4-for-2.6.16-4 recommended.
I stress tested this patch for 18hrs on my machine, and it seems stable. Thanks for the update and warning. On Wed, 2006-08-02 at 23:55 +0400, Alexander Zarochentsev wrote: > Hello, > > reiser4-for-2.6.16-4.patch contains a bug which can cause fs corruption > (it is the same bug as is in the first reiser4 patches for > linux-2.6.17, now fixed). > > If you use that buggy patch, please upgrade you kernel and reiser4 code > to 2.6.17/reiser4-for-2.6.17-3 or use new reiser4-for-2.6.16-5.patch.gz > from ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.16/. > > The bug fix is available as a separate patch > reiser4-for-2.6.16-4--missing-unlock-fix.diff at > ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.16/hotfixes/ > > -- > Alex. > -- Jake Maciejewski <[EMAIL PROTECTED]>
[nikita-3002]: assertion failed: carry_level_invariant(doing, CARRY_DOING)
Hello, Every few weeks reiser4 panics on me, generally while kmail is receiving emails. Until recently, the panic was "invalid opcode: [#1]" (previously reported), but I have some new errors: The first is: reiser4 panicked cowardly: reiser4[less(7234)]: set_file_state (fs/reiser4/plugin/file/file.c:200)[vs-1162]: assertion failed: ergo(level == LEAF_LEVEL && cbk_result == CBK_COORD_FOUND, uf_info->container == UF_CONTAINER_TAILS) Kernel panic - not syncing: reiser4[less(7234)]: set_file_state (fs/reiser4/plugin/file/file.c:200)[vs-1162]: assertion failed: ergo(level == LEAF_LEVEL && cbk_result == CBK_COORD_FOUND, uf_info->container == UF_CONTAINER_TAILS) and the second is: reiser4[patch(25956)]: carry_level_invariant (fs/reiser4/carry.c:1250)[]: WARNING: wrong key order reiser4 panicked cowardly: reiser4[patch(25956)]: carry_on_level (fs/reiser4/carry.c:356)[nikita-3002]: assertion failed: carry_level_invariant(doing, CARRY_DOING) Kernel panic - not syncing: reiser4[patch(25956)]: carry_on_level (fs/reiser4/carry.c:356)[nikita-3002]: assertion failed: carry_level_invariant(doing, CARRY_DOING) Both were for 2.6.18-rc2-mm1 [1]. The second error occurred on a recently fscked filesystem. [1] with one patch reverted for unrelated reasons. I hope this helps get to the root of the problem. Unfortunately, I do not yet have a reproduceable test case. Andrew Wade
new reiser4 patch for linux-2.6.16 is available, upgrade from reiser4-for-2.6.16-4 recommended.
Hello, reiser4-for-2.6.16-4.patch contains a bug which can cause fs corruption (it is the same bug as is in the first reiser4 patches for linux-2.6.17, now fixed). If you use that buggy patch, please upgrade you kernel and reiser4 code to 2.6.17/reiser4-for-2.6.17-3 or use new reiser4-for-2.6.16-5.patch.gz from ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.16/. The bug fix is available as a separate patch reiser4-for-2.6.16-4--missing-unlock-fix.diff at ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.16/hotfixes/ -- Alex.
Re: metadata plugins (was Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion)
Dnia Wed, 02 Aug 2006 20:45:07 +0200, Horst H. von Brand <[EMAIL PROTECTED]> napisał: Vladimir V. Saveliev <[EMAIL PROTECTED]> wrote: On Tue, 2006-08-01 at 17:32 +0200, Å�ukasz Mierzwa wrote: > Dnia Fri, 28 Jul 2006 18:33:56 +0200, Linus Torvalds <[EMAIL PROTECTED]> > napisaÅ‚: > > In other words, if a filesystem wants to do something fancy, it needs to > > do so WITH THE VFS LAYER, not as some plugin architecture of its own. We > > already have exactly the plugin interface we need, and it literally _is_ > > the VFS interfaces - you can plug in your own filesystems with > > "register_filesystem()", which in turn indirectly allows you to plug in > > your per-file and per-directory operations for things like lookup etc. > What fancy (beside cryptocompress) does reiser4 do now? it is supposed to provide an ability to easy modify filesystem behaviour in various aspects without breaking compatibility. If it just modifies /behaviour/ it can't really do much. And what can be done here is more the job of the scheduler, not of the filesystem. Keep your hands off it! You modify the way the fs stores files or let You access them, since when it is a job for a scheduler? If it somehow modifies /on disk format/, it (by *definition*) isn't compatible. Ditto. > Can someone point me to a list of things that are required by kernel > mainteiners to merge reiser4 into vanilla? list of features reiser4 does not have now: O_DIRECT support - we are working on it now various block size support Is this required? quota support xattrs and acls Without those, it is next to useless anyway. I don't use any of this and I live quite happly.
Re: metadata plugins (was Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion)
Vladimir V. Saveliev <[EMAIL PROTECTED]> wrote: > On Tue, 2006-08-01 at 17:32 +0200, Åukasz Mierzwa wrote: > > Dnia Fri, 28 Jul 2006 18:33:56 +0200, Linus Torvalds <[EMAIL PROTECTED]> > > napisaÅ: > > > In other words, if a filesystem wants to do something fancy, it needs to > > > do so WITH THE VFS LAYER, not as some plugin architecture of its own. We > > > already have exactly the plugin interface we need, and it literally _is_ > > > the VFS interfaces - you can plug in your own filesystems with > > > "register_filesystem()", which in turn indirectly allows you to plug in > > > your per-file and per-directory operations for things like lookup etc. > > What fancy (beside cryptocompress) does reiser4 do now? > > it is supposed to provide an ability to easy modify filesystem behaviour > in various aspects without breaking compatibility. If it just modifies /behaviour/ it can't really do much. And what can be done here is more the job of the scheduler, not of the filesystem. Keep your hands off it! If it somehow modifies /on disk format/, it (by *definition*) isn't compatible. Ditto. > > Can someone point me to a list of things that are required by kernel > > mainteiners to merge reiser4 into vanilla? > > list of features reiser4 does not have now: > O_DIRECT support - we are working on it now > various block size support Is this required? > quota support > xattrs and acls Without those, it is next to useless anyway. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513
Re: Solaris ZFS on Linux
Krzysztof Halasa wrote: Kyle Moffett <[EMAIL PROTECTED]> writes: IMHO the best alternative for a situation like that is a storage controller with a battery-backed cache and a hunk of flash NVRAM for when the power shuts off (just in case you run out of battery), as well as a separate 1GB battery-backed PCI ramdisk for an external journal device (likewise equipped with flash NVRAM). It doesn't take Not sure - reading flash is fast, but writing is quite slow. A digital camera can consume a set of 2 or 4 2500 mAh AA cells for a fraction of 1 GB (of course, only a part of power goes to flash). Yeah - that's why I said in the original message that it's not especially lower in energy - the energy is used at a lower rate, so is much cheaper to supply. http://www.samsung.com/products/semiconductor/NORFlash/256Mbit/K8A5615EBA/K8A5615EBA.htm 's datasheet says to program the 32Mbyte chip takes about 30mw*120s, or 3.5J or so. For a gigabyte, that's 100J - a fairly substantial amount of energy. However - it's at a low rate, so it's not _too_ expensive to supply.
Re: [BUG] nikita-1481, nikita-717 and nikita-373 here and there
Hello,
On Wednesday 02 August 2006 00:39, Craig Shelley wrote:
> On Fri, 2006-06-23 at 02:51 +0300, Jussi Judin wrote:
> > After that I upgraded to Debian patched kernel 2.6.16-14 and to
> > reiser4 patch 2.6.16-4 for that kernel and ran fsck.reiser4. Then I
> > got errors like this in kern.log after a while:
> >
> > WARNING: Error for inode 1731981 (-2)
> > reiser4[nfsd(3817)]: key_warning
> > (fs/reiser4/plugin/file_plugin_common.c:513)[nikita-717]:
> > WARNING: Error for inode 1703086 (-2)
> > reiser4[nfsd(3818)]: key_warning
> > (fs/reiser4/plugin/file_plugin_common.c:513)[nikita-717]:
> > WARNING: Error for inode 1726433 (-2)
> > reiser4[nfsd(3818)]: key_warning
> > (fs/reiser4/plugin/file_plugin_common.c:513)[nikita-717]:
>
> I too am getting these warnings:
>
> Jul 27 06:28:15 prometheus kernel: reiser4[find(10770)]: key_warning
> (fs/reiser4/plugin/file_plugin_common.c:513)[nikita-717]:
> Jul 27 06:28:15 prometheus kernel: WARNING: Error for inode 3922698
> (-2) [REPEATED 17 TIMES]
> Jul 27 06:28:15 prometheus kernel: reiser4[find(10770)]: key_warning
> (fs/reiser4/plugin/file_plugin_common.c:513)[nikita-717]:
> Jul 27 06:28:15 prometheus kernel: WARNING: Error for inode 3922697
> (-2) [REPEATED 17 TIMES]
> Jul 27 06:28:16 prometheus kernel: reiser4[find(10770)]: key_warning
> (fs/reiser4/plugin/file_plugin_common.c:513)[nikita-717]:
> Jul 27 06:28:16 prometheus kernel: WARNING: Error for inode 3922696
> (-2) [REPEATED 17 TIMES]
>
> ...
> ...
>
> Jul 27 06:28:19 prometheus kernel: reiser4[find(10770)]:
> cbk_level_lookup (fs/reiser4/search.c:961)[vs-3533]:
> Jul 27 06:28:19 prometheus kernel: WARNING: Keys are inconsistent.
> Fsck? Jul 27 06:28:19 prometheus kernel: reiser4[find(10770)]:
> key_warning (fs/reiser4/plugin/file_plugin_common.c:513)[nikita-717]:
> Jul 27 06:28:19 prometheus kernel: WARNING: Error for inode 3922690
> (-5)
>
>
> System information:
> Kernel: 2.6.16.20
> Patches: reiser4-for-2.6.16-4.patch.gz
please upgrade to 2.6.17 and reiser4-for-2.6.17-3
or apply the following patch:
Index: linux-2.6.16/fs/reiser4/plugin/file/file.c
===
--- linux-2.6.16.orig/fs/reiser4/plugin/file/file.c
+++ linux-2.6.16/fs/reiser4/plugin/file/file.c
@@ -1633,14 +1633,18 @@ static size_t read_file(hint_t * hint, s
/* error happened */
break;
- if (coord->between != AT_UNIT)
+ if (coord->between != AT_UNIT) {
/* there were no items corresponding to given offset */
+ done_lh(hint->ext_coord.lh);
break;
+ }
loaded = coord->node;
result = zload(loaded);
- if (unlikely(result))
+ if (unlikely(result)) {
+ done_lh(hint->ext_coord.lh);
break;
+ }
if (hint->ext_coord.valid == 0)
validate_extended_coord(&hint->ext_coord,
@@ -1725,13 +1729,15 @@ ssize_t read_unix_file(struct file *file
left = size - *off;
/* faultin user page */
- result = fault_in_pages_writeable(buf, left > PAGE_CACHE_SIZE ?
PAGE_CACHE_SIZE : left);
- if (result) {
+ if(fault_in_pages_writeable(buf, left > PAGE_CACHE_SIZE ?
PAGE_CACHE_SIZE : left)) {
drop_nonexclusive_access(uf_info);
- return RETERR(-EFAULT);
+ result = RETERR(-EFAULT);
+ break;
}
- read = read_file(hint, file, buf, left, off);
+ read = read_file(hint, file, buf,
+left > PAGE_CACHE_SIZE ? PAGE_CACHE_SIZE :
left,
+off);
drop_nonexclusive_access(uf_info);
@@ -1748,6 +1754,7 @@ ssize_t read_unix_file(struct file *file
count += read;
}
save_file_hint(file, hint);
+ done_lh(&hint->lh);
kfree(hint);
if (count) {
Index: linux-2.6.16/fs/reiser4/as_ops.c
===
--- linux-2.6.16.orig/fs/reiser4/as_ops.c
+++ linux-2.6.16/fs/reiser4/as_ops.c
@@ -350,6 +350,9 @@ int reiser4_releasepage(struct page *pag
if (PageDirty(page))
return 0;
+ if (page_count(page) > 3)
+ return 0;
+
/* releasable() needs jnode lock, because it looks at the jnode fields
* and we need jload_lock here to avoid races with jload(). */
spin_lock_jnode(node);
> Reiser4progs: 1.0.5
>
> This machine is used for recording TV using a DVB card, compresses
> the files, and serves them via NFS and Samba.
>
> Until recently, the system ran kernel linux-2.6.11.6, and performed
> flawlessly for over a year. After upgrading the kernel, I upgraded
> reiser4pr
Re: Solaris ZFS on Linux
Kyle Moffett <[EMAIL PROTECTED]> writes: > IMHO the best alternative for a situation like that is a storage > controller with a battery-backed cache and a hunk of flash NVRAM for > when the power shuts off (just in case you run out of battery), as > well as a separate 1GB battery-backed PCI ramdisk for an external > journal device (likewise equipped with flash NVRAM). It doesn't take > much power at all to write a gig of stuff to a small flash chip > (Think about your digital camera which runs off a couple AA's), so > with a fair-sized on-board battery pack you could easily transfer its > data to NVRAM and still have power left to back up data in RAM for 12 > hours or so. That way bootup is fast (no reading 1GB of data from > NVRAM) but there's no risk of data loss. Not sure - reading flash is fast, but writing is quite slow. A digital camera can consume a set of 2 or 4 2500 mAh AA cells for a fraction of 1 GB (of course, only a part of power goes to flash). -- Krzysztof Halasa
Re: reiserfs 3.6 with 2TB file size limitation!
--- Edward Shishkin <[EMAIL PROTECTED]> wrote: > Ricardo (Tru64 User) wrote: > > Hi, > > Hello > > > I read on reiserfs site, faq #1, about max file > sizes: > > max file size 2^60 - bytes => 1 Ei, > > but page cache limits this to 8 Ti on > architectures > > with 32 bit int for reiserfs 3.6 > > > > I do have a reiserfs 3.6 filesystem, on kernel > > 2.6.12-21mdksmp (mandriva 2006) that would not > take a > > filesize greater than 2TB! > > > > Filesize in question:: > > -rw-r--r-- 1 myuser users 2147483647 Aug 1 16:41 > > myfile.out > > Hmm.. actually this file has size 2GB, not 2TB. > Did you try to specify O_LARGEFILE when creating a > file? > (man creat) > > > > > Error received: > > "Filesize limit exceeded" > > > > This filesystem is on a scsi device connected via > > Adaptec AIC-7899P U160/m card (if it matters). > > > > # debugreiserfs /dev/sda1 > > debugreiserfs 3.6.19 (2003 www.namesys.com) > > > > > > Filesystem state: consistency is not checked after > > last mounting > > > > Reiserfs super block in block 16 on 0x801 of > format > > 3.6 with standard journal > > Count of blocks on the device: 292967356 > > Number of bitmaps: 8941 > > Blocksize: 4096 > > Free blocks (count of blocks - used [journal, > bitmaps, > > data, reserved] blocks): 172310677 > > Root block: 121672 > > Filesystem is NOT clean > > Tree height: 5 > > Hash function used to sort names: "r5" > > Objectid map size 2, max 972 > > Journal parameters: > > Device [0x0] > > Magic [0x5613f7b2] > > Size 8193 blocks (including 1 for journal > > header) (first block 18) > > Max transaction length 1024 blocks > > Max batch size 900 blocks > > Max commit age 30 > > Blocks reserved by journal: 0 > > Fs state field: 0x0: > > sb_version: 2 > > inode generation number: 1507612 > > UUID: 78e233e1-8210-4c9f-8f5d-7159c754db16 > > LABEL: > > Set flags in SB: > > ATTRIBUTES CLEAN > > > > Any idea why i would receive this limitation, with > a > > 2.6 kernel and reiserfs 3.6? Can this be corrected > to > > allow the full file size? > > I would appreciate any hints > > I check the kernel-sources for the kernel version > i am > > running, and i dont see any mention of "large > > file/filesystem support" that i recall was > available > > in older kernel compiles, so it is probably > > integrated now? > > > > > > _Thanks > > > > Richard Ohh yes.my (user's) fault. This is an application limitation (fortran) probably for not using the right switch. And, yes, the file size i posted is only 2gb! Please ignore this post. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
