[DragonFlyBSD - Bug #2064] (Rejected) Result too large -> no header -> RO hammerfs works

[Alex Hornung via Redmine <bugtracker-admin@xxxxxxxxxxxxxxxxxxxxx>]

Issue #2064 has been updated by Alex Hornung.

Description updated
Status changed from New to Rejected
Assignee deleted (0)


----------------------------------------
Bug #2064: Result too large -> no header -> RO hammerfs works
http://bugs.dragonflybsd.org/issues/2064

Author: Diego Cad
Status: Rejected
Priority: Normal
Assignee: 
Category: 
Target version: 


Hi dragons,

i've been around HAMMER for linux past days, after a couple of typos it 
worked nice for Ubuntu running 2.6.37-39. even since the driver had no 
updates since 2009 (?)

1. tut 2 DF running virtualized? i use hless vbox lately with success.

2. still on that 'no header' dmesg sysout on Linux for the relative to \

dragonfoo# mount_hammer: mount on /tmp/fs: Result too large  ->
followup ->    /4d5c172f$0$927$415eb37d@crater_reader.dragonflybsd.org

3. could more ram result into a larger REDO tables ending in succes?
    it is likely that the 'Result too large' for RW mount comes from 
available ram to allocate the REDO tables? then what does that 'no 
header' means (dfbsd and linux) but RO data is untouched.
basically i have 3gig ram and 160g hdd. REDO switches almost 
automatically since last time the box was processing several i mean 
several simultaneous processes (like 40 concurrent RW + 4 makes) then
the REDO as for reordering the last data flushes becomes without enough 
dynamic allocation? it's more likely that it does not relate to HDD 
space as originally thought even if the drive is 25% free capacity under 
that load circumstances.

thx
Diego


-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account