union fs

union fs

[RvP]

Hi,

Support for unionfs-modules with recent kernels is broken in oe, see
http://bugs.openembedded.org/show_bug.cgi?id=1189.

Are there plans to fix this?

Re: union fs

[Mike (mwester)]

RvP wrote:
> Hi,
> 
> Support for unionfs-modules with recent kernels is broken in oe, see
> http://bugs.openembedded.org/show_bug.cgi?id=1189.
> 
> Are there plans to fix this?

The unionfs modules are part of the 2.6 kernel now.  Do you really need 
them?

Unslung is the only distro AFAIK that is still based on a 2.4 kernel; 
and unionfs is not very useful (the obvious use, which is to use ntfs-3g 
to replace the buggy Linksys proprietary ntfs driver is not write-safe, 
and thus isn't useful).

I would suspect that we can simply drop the modules build from unionfs. 
  (But perhaps leave the recipe present in case someone else wants very 
much to try to get ntfs-3g working on unslung.)

Mike (mwester)

Re: union fs

[RvP]

From: "Mike (mwester)" <mwester@dls.net>
> RvP wrote:
> > Hi,
> > 
> > Support for unionfs-modules with recent kernels is broken in oe, see
> > http://bugs.openembedded.org/show_bug.cgi?id=1189.
> > 
> > Are there plans to fix this?
> 
> The unionfs modules are part of the 2.6 kernel now. 

Are they? I read on the unionfs site that they are part of the -mm tree as of
Jan. 2007, but, you're probably right. OpenWRT does use unionfs per default
with a 2.6.24 kernel.

> Do you really need them?

Not anymore, I was looking for a way to install extra pakages for SlugOS on
an external drive. I found in the docs that a copy of the complete rootfs can
be installed on an external drive using 'turnup' (NSLU2 specific tool). I'll
go that way.

Thanks,

Richard.

Re: union fs

[Mike (mwester)]

RvP wrote:
> From: "Mike (mwester)" <mwester@dls.net>
>> RvP wrote:
>>> Hi,
>>>
>>> Support for unionfs-modules with recent kernels is broken in oe, see
>>> http://bugs.openembedded.org/show_bug.cgi?id=1189.
>>>
>>> Are there plans to fix this?
>> The unionfs modules are part of the 2.6 kernel now. 
> 
> Are they? I read on the unionfs site that they are part of the -mm tree as of
> Jan. 2007, but, you're probably right. OpenWRT does use unionfs per default
> with a 2.6.24 kernel.

No, you're right - I looked more closely, it's still not made it into 
the 2.6.24 kernel.

>> Do you really need them?
> 
> Not anymore, I was looking for a way to install extra pakages for SlugOS on
> an external drive. I found in the docs that a copy of the complete rootfs can
> be installed on an external drive using 'turnup' (NSLU2 specific tool). I'll
> go that way.
> 
> Thanks,
> 
> Richard.

Cool.  Turnup is the right way to do it with SlugOS.  But I do still 
plan to get unionfs into the SlugOS feeds at some point.  It does look 
like at the moment that means fixing that recipe somehow; something that 
won't be simple (since the patch downloaded depends on the kernel 
version the recipe is being built for).

Thanks,
Mike (mwester)

Re: union fs

[Szabolcs Szakacsits]

Mike (mwester <mwester <at> dls.net> writes:
> 
> Unslung is the only distro AFAIK that is still based on a 2.4 kernel; 
> and unionfs is not very useful (the obvious use, which is to use ntfs-3g 
> to replace the buggy Linksys proprietary ntfs driver is not write-safe, 
> and thus isn't useful).
> 
> I would suspect that we can simply drop the modules build from unionfs. 
>   (But perhaps leave the recipe present in case someone else wants very 
> much to try to get ntfs-3g working on unslung.)

What do you mean ntfs-3g is not write safe? Nobody ever told us.

It's certainly used and certified on several ARM and MIPS embedded devices 
regularly.

Regards,  Szaka

--
NTFS-3G: http://ntfs-3g.org

Package_arch for x86 architectures

[Stelios Koroneos]

It has been discussed in the past on the irc also, but it seems we are
reaching a "limit" with the existing package_arch namespace for the x86
variant.
The x86 architecture is generaly a mess as hrw has pointed in his blog.
This creates a problem as we now have package arches like
i486,i586,i686,geode, (just to name a few) with different gcc -march and
-mtune settings and there also a  couple lile x86-32-nocona that use a
different -march but still use i686 as the package_arch
This could lead to troubles if you maintain a multimachine feed as you are
going to mix packages build with different optimizations that migh not run
well (or at all) 

There are also new embedded (and non embedded) boards coming that will
require also a package_arch.

For example I am working on an intel D201gly2 machine definition. This is a
P4 Celleron architecture cpu so I need to use -march=pentium4 mtune=celeron
How should this package_arch be named ?  i686p4c ? p4c ?
Should we have a "common" namespace ? How about geode based machines ?

Looking for input from interested parties before we move to rfc something
like that

Stelios S. Koroneos

Digital OPSiS - Embedded Intelligence
http://www.digital-opsis.com
 

Re: union fs

[Mike (mwester)]

Szabolcs Szakacsits wrote:

> What do you mean ntfs-3g is not write safe? Nobody ever told us.
> 
> It's certainly used and certified on several ARM and MIPS embedded devices 
> regularly.
> 
> Regards,  Szaka

According to the official docs, due to limitations of the fuse driver 
for 2.4 kernels, ntfs-3g on such old kernels is prone to data loss. 
This is a fuse problem, but effectively if you value your NTFS 
partition's consistency, it means that ntfs-3g on such old kernels 
should be read-only.

On 2.6, ntfs-3g works wonderfully on all the devices in read and write 
modes, and is the driver I recommend for NTFS support on the SlugOS 
(ARM) distro.

Sorry for not being more clear.

Mike (mwester)

Re: union fs

[Szabolcs Szakacsits]

Mike (mwester <mwester <at> dls.net> writes:
> 
> According to the official docs, due to limitations of the fuse driver 
> for 2.4 kernels, ntfs-3g on such old kernels is prone to data loss. 
> This is a fuse problem, but effectively if you value your NTFS 
> partition's consistency, it means that ntfs-3g on such old kernels 
> should be read-only.
> 
> On 2.6, ntfs-3g works wonderfully on all the devices in read and write 
> modes, and is the driver I recommend for NTFS support on the SlugOS 
> (ARM) distro.
> 
> Sorry for not being more clear.

I see, thank you for the explanation. I think we should have better documented 
this ntfs-3g issue, sorry about it.

Everything is as safe with the 2.4 kernels as with the 2.6 ones if after umount 
one makes sure that the ntfs-3g process is terminated before a device is 
detached or the box is powered down. This can be ensured automatic e.g. by a 
few shell commands. 

Regards,  Szaka

--
NTFS-3G: http://ntfs-3g.org