[Tux3] Review incoming changes

[Maciej Żenczykowski]

changing the order of autodetection isn't enough - you'd also need to
make sure the magic files are up2date - also on old computers and make
it somehow not mount as reiserfs even if someone explicitely asks for
reiserfs - that's why I vote for pre-emptively zeroing out a megabyte
on both sides - what are the drawbacks?  I see none...

On Tue, Dec 16, 2008 at 02:46, OGAWA Hirofumi
<hirofumi at mail.parknet.co.jp> wrote:
> "Maciej �*wenczykowski" <zenczykowski at gmail.com> writes:
>
>>> IIRC, MD RAID is using final 64kb. I think we should clear the top
>>> 1024bytes and final 64kb. (And with it, to make sure, we would check if
>>> volume size is bigger than 64kb, instead of clearing 64kb blindly.)
>>
>> You definitely want to clear at least 4 kB, and probably 8 kB at the
>> front
>
> Why?
>
>> -- for example - the first 1kB of my root partition is all
>> zeroes because ext3 skips the first kb to leave room for a partition
>> table or boot sector or what not.
>
> I know, actually mke2fs _does_ clear the first 1kb if it is not disabled.
>
>> My suggestion would be to clear both the first and last 1 MB - if it
>> fits in the available space on the volume.
>> Reasoning?
>> For example in /usr/share/file/magic:
>> 0x10034><------>string<>ReIsErFs<------>ReiserFS V3.5
>>
>> So it seems reiserfs's signature is at just past 64kB (as is UFS's in
>> some variants).
>> and there are many examples past 1kB, some past 32kB (isos for example)
>>
>> In general clearing out too much shouldn't hurt - it's not like this
>> is a performance issue, clearing out too little may be problematic and
>> cause issues later on - better to be safe then sorry...
>
> It doesn't guarantee anything. Because those blocks can be data blocks
> on many fs, auto-detecter should just change the detection order instead.
>
> Thanks.
>
>
> Szabolcs Szakacsits <szaka at ntfs-3g.org> writes:
>
>>> > Ah, I was forgetting about it. I think, first 1024bytes (FAT, NTFS, and
>>> > EFI), and last 64kbytes (EFI, and MD RAID), should be enough. Right?
>>> Please, let us be on the safe side, and do the first 256k or even 1M each.
>>> FAT stores a backup boot sector, and that is typically in the 11th sector, but
>>> it can be nearly anywhere else.
>>>
>>> So I'd beg for the minimum of 64kB at start at end - and if it doesn't cost
>>> too much, please 1M.
>>
>> Afair, reiserfs puts signature at 128 kB. NTFS may also have a backup at
>> the middle of the volume.
>
> I see. Well, auto detection is not perfect always, rather it's mess
> historically.
>
> However, if zeroed the boot sector is not enough for NTFS, in theory, we
> can't detect NTFS even if it's FAT actually?  Because the middle of the
> volume may be data block on FAT. So, we can't do anything for it.
> Instead, NTFS driver or auto-detect engine have to do something, if it
> wants.
>
> Anyway, the solution for auto-detection would change the detection
> order, i.e. try to detect tux3 before reiserfs and NTFS.  Because tux3
> put superblock at 4096 offset for now, and other blocks can be used for
> any purpose.
>
> So I think, mkfs clears first 1024b (or 4096b) and last 64kb, at least
> for now, it is enough?
>
> Thanks.
> --
> OGAWA Hirofumi <hirofumi at mail.parknet.co.jp>
>
_______________________________________________
Tux3 mailing list
Tux3 at tux3.org
http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3