On Thu, May 24, 2012 at 09:58:52PM +0200, Matthew Seaman wrote:
> On 24/05/2012 00:05, Mark Linimon wrote:
> > On Wed, May 23, 2012 at 10:58:48PM +0100, Steven Hartland wrote:
> >> > While it might be a shame to see FFS go by the wayside are there any
> >> > big reasons why you would rather stick w
On 2012-May-24 12:04:21 +0400, Lev Serebryakov wrote:
> I afraid, that after real hardware failure (like real HDD death,
>not these pseudo-broken-hardware situations, when HDDs is perfectly
>alive and in good condition), all data will be lost. I could restore
>data from remains of FFS by hands (f
On 24/05/2012 00:05, Mark Linimon wrote:
On Wed, May 23, 2012 at 10:58:48PM +0100, Steven Hartland wrote:
> While it might be a shame to see FFS go by the wayside are there any
> big reasons why you would rather stick with FFS instead of moving
> to ZFS with all the benefits that brings?
- Z
On 24/05/2012 00:05, Mark Linimon wrote:
> On Wed, May 23, 2012 at 10:58:48PM +0100, Steven Hartland wrote:
>> > While it might be a shame to see FFS go by the wayside are there any
>> > big reasons why you would rather stick with FFS instead of moving
>> > to ZFS with all the benefits that brings?
On 24/05/2012 00:05, Mark Linimon wrote:
> On Wed, May 23, 2012 at 10:58:48PM +0100, Steven Hartland wrote:
>> > While it might be a shame to see FFS go by the wayside are there any
>> > big reasons why you would rather stick with FFS instead of moving
>> > to ZFS with all the benefits that brings?
On 23. May 2012, at 21:38 , Lev Serebryakov wrote:
> Hello, Konstantin.
> You wrote 23 мая 2012 г., 17:10:46:
>
> KB> This panic is another protective panic caused by on-disk inconsistent
> KB> structures. The bitmap indicated that an inode was free, but actual inode
> KB> context suggested that
If all you are doing is reading, the ZFS on-disk format is well documented
and fairly easy to work with. Take a look at the ZFS bootloader code - that
implements a ZFS reader in not too many lines of code and could easily be
re-purposed for a recovery tool.
On 24 May 2012 09:04, Lev Serebryakov w
Hello, Steven.
You wrote 24 мая 2012 г., 1:58:48:
SH> While it might be a shame to see FFS go by the wayside are there any
SH> big reasons why you would rather stick with FFS instead of moving
SH> to ZFS with all the benefits that brings?
I afraid, that after real hardware failure (like real HDD
- Original Message -
From: "Mark Linimon"
On Wed, May 23, 2012 at 10:58:48PM +0100, Steven Hartland wrote:
While it might be a shame to see FFS go by the wayside are there any
big reasons why you would rather stick with FFS instead of moving
to ZFS with all the benefits that brings?
On Wed, May 23, 2012 at 10:58:48PM +0100, Steven Hartland wrote:
> While it might be a shame to see FFS go by the wayside are there any
> big reasons why you would rather stick with FFS instead of moving
> to ZFS with all the benefits that brings?
- ZFS eats bytes for breakfast. It is completely
- Original Message -
From: "Lev Serebryakov"
Or should we call FFS officially dead and promote ZFS as only usable
FS on modern FreeBSD now?
Slightly OT but I must say I'm a big fan of ZFS since I first tried it under
FreeBSD a few years back.
Not only is it a dream to use as an admi
Hello, Konstantin.
You wrote 23 мая 2012 г., 17:10:46:
KB> This panic is another protective panic caused by on-disk inconsistent
KB> structures. The bitmap indicated that an inode was free, but actual inode
KB> context suggested that the inode is in use.
KB> I would not worry much about ffs code
On Wed, May 23, 2012 at 12:40:34AM +, Bjoern A. Zeeb wrote:
> Hi,
>
> I have a machine that since updated to r235609 started to constantly panic
> in the FS code while building universe, first with
>
> ufs_dirbad: /scratch: bad dir ino 1137225 at offset 17920: mangled entry
>
> which a clri
13 matches
Mail list logo
