[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: moving affs + RDB partition support to staging?




> On May 6, 2018, at 4:27 PM, Eero Tamminen <oak@helsinkinet.fi> wrote:
> 
> Hi,
> 
> On 05/06/2018 03:10 PM, John Paul Adrian Glaubitz wrote:
>>>> On May 6, 2018, at 1:52 PM, Eero Tamminen <oak@helsinkinet.fi> wrote:
>>>>> On 05/06/2018 01:12 PM, Martin Steigerwald wrote:
>>>>> Al Viro - 06.05.18, 02:59:
>>>>> Funny, that...  I'd been going through the damn thing for the
>>>>> last week or so; open-by-fhandle/nfs export support is completely
>>>>> buggered.  And as for the rest... the least said about the error
>>>>> handling, the better - something like rename() hitting an IO
>>>>> error (read one) can not only screw the on-disk data into the
>>>>> ground, it can do seriously bad things to kernel data structures.
>>>>> 
>>>>> Is there anything resembling fsck for that thing, BTW?  Nevermind
>>>>> the repairs, just the validity checks would be nice...
>>>> I am not aware of the fsck command for affs on Linux. There is a
>>>> partitioning tool called amiga-fdisk, but for checking a filesystem you
>>>> would need to use a tool under AmigaOS.
>>> 
>>> So, it should be made read-only FS, until the problems are
>>> fixed (and there's linux-native FS consistency checker)?
>> No, it shouldn’t.
>>> Read-only mode should be enough for the data rescue purposes
>>> mentioned in the list.
> 
> I meant read-only by default...
> 
> 
>> This is for the second usecase I mentioned. The first usecase requires write access.
> 
> ...So anybody wanting to do writes with it, would need to enable
> that him/herself and read warnings about it being unsafe and
> about the importance of doing backups before enabling/using it.
> 
> (Similarly to NTFS support, before its write side was stable.)
> 
> 
>> Again, it works fine for our usecases in Debian m68k,
>> so please don’t mutilate its functionality.
> 
> Based on above comments, that's only by luck.  I'd assume
> disks still having AFFS on them to be fairly old and therefore
> rather likely to get IO errors.  Moving new files on the disk
> is likely to involve file renames for the old ones.

It never broke for me on a single instance and I use it regularly. Really.

These discussions are extremely frustrating to the point that I just want to leave. Just stop it!

Don’t make decisions based on assumptions unless you have actual data and not some constructed theoretical situation.

Adrian

Reply to: