Bug 1078552

file systems as TODO is already reported. But mounting previously formatted volume should work.

Ancor - is it known issue that it cannot be mounted?

TODO labels were replaced by correct data in version 4.0.73 of package yast2-storage-ng. What version is used in your build image?

And please, could you attach y2logs? See https://en.opensuse.org/openSUSE:Report_a_YaST_bug#I_reported_a_YaST2_bug.2C_and_now_I_am_asked_to_.22attach_y2logs.22_.28for_package_installation_also_.22libzypp_logging.22.29._What_does_that_mean.2C_and_how_do_I_do_that.3F

(In reply to Josef Reidinger from comment #1)
> file systems as TODO is already reported. But mounting previously formatted
> volume should work.

Sorry, it wasn't the 'FS type' column, it is called just 'Type'. 

The option to mount can't be selected.  This is a JFS volume - with e.g. ext4, it works.  Oh, I see, it isn't even recognised as a JFS volume.

(In reply to José Iván López González from comment #2)
> TODO labels were replaced by correct data in version 4.0.73 of package
> yast2-storage-ng. What version is used in your build image?

Whatever was in the repo - 

I presume:
yast2-storage-ng-4.0.76-lp150.1.1.noarch.rpm

(In reply to Per Jessen from comment #4)
> (In reply to José Iván López González from comment #2)
> > TODO labels were replaced by correct data in version 4.0.73 of package
> > yast2-storage-ng. What version is used in your build image?
> 
> Whatever was in the repo - 
> 
> I presume:
> yast2-storage-ng-4.0.76-lp150.1.1.noarch.rpm

Looks like this was only just pushed out to the mirrors in the last hour or so. I am just now running a new installatrion, the TODO is gone.  I still can't mount the volume with a JFS filesystem.

(In reply to Per Jessen from comment #3)
>
> The option to mount can't be selected.  This is a JFS volume - with e.g.
> ext4, it works.  Oh, I see, it isn't even recognised as a JFS volume.

JFS support is being dropped. That's intentional.

(In reply to Ancor Gonzalez Sosa from comment #6)
> (In reply to Per Jessen from comment #3)
> >
> > The option to mount can't be selected.  This is a JFS volume - with e.g.
> > ext4, it works.  Oh, I see, it isn't even recognised as a JFS volume.
> 
> JFS support is being dropped. That's intentional.

How do we mount existing filesystems then?  I guess it's not important to you, but for us that is a complete show-stopper.  Would upgrades work?

(In reply to Ancor Gonzalez Sosa from comment #6)
> (In reply to Per Jessen from comment #3)
> >
> > The option to mount can't be selected.  This is a JFS volume - with e.g.
> > ext4, it works.  Oh, I see, it isn't even recognised as a JFS volume.
> 
> JFS support is being dropped. That's intentional.

Is that because support for JFS upstream has been dropped?


But ... Let me get this right.
You're dropping support for JFS and for ReiserFS.
They are both B-tree file systems that support dynamic allocation, rather than the fixed-at-mkfs-time of Ext4.

That fixed-at-mkfs-time attitude dates back to the 1960s/1970s and the original UNIX simple & limited kernel code space attitudes.  The professional/commercial systems such as AIX etc aren't stuck in this antediluvian attitudes.  AIX is where JFS originated.

Will that last remaining "other" FS that uses dynamic allocation, XFS, be depreciated as well, forcing us to use BtrFS -- the "one file system to rule all disks" FS -- if there is any uncertainty about the way storage will be used?

(In reply to Per Jessen from comment #7)
> (In reply to Ancor Gonzalez Sosa from comment #6)
> > (In reply to Per Jessen from comment #3)
> > >
> > > The option to mount can't be selected.  This is a JFS volume - with e.g.
> > > ext4, it works.  Oh, I see, it isn't even recognised as a JFS volume.
> > 
> > JFS support is being dropped. That's intentional.
> 
> How do we mount existing filesystems then?  I guess it's not important to
> you, but for us that is a complete show-stopper.  Would upgrades work?

I don't think upgrades will work. And handling of existing filesystems will need to be done "by hand", the installer and the Expert Partitioner will not handle those filesystems, AFAIK.

(In reply to Anton Aylward from comment #8)
>
> Is that because support for JFS upstream has been dropped?

Yes, I think so.

> But ... Let me get this right.
> You're dropping support for JFS and for ReiserFS.

Both has been discontinued by upstream, not (open)SUSE. That leaves very few options for us.

> Will that last remaining "other" FS that uses dynamic allocation, XFS, be
> depreciated as well

I don't think XFS will fall in disgrace in the Linux kernel and/or upstream community anytime soon. But that's out of our control.

So I'm closing the bug because the TODOs are gone and the drop of JFS support is intentional. Works as expected.

On the other hand. If your are not satisfied with the answers I have added Jiri Srain and Arvin to CC. They can give you better insights about the reasons behind such decision.

(In reply to Ancor Gonzalez Sosa from comment #9)
> (In reply to Anton Aylward from comment #8)
> >
> > Is that because support for JFS upstream has been dropped?
> 
> Yes, I think so.
>
> > But ... Let me get this right.
> > You're dropping support for JFS and for ReiserFS.
> 
> Both has been discontinued by upstream, not (open)SUSE. That leaves very few
> options for us.

Which upstream is that?   JFS is alive and well, afaict.

JFS drop is old feature number 2105 ( sorry private only as it is really ancient ).

Quoting from it (not all info is up to date, consider that it is 11 years old, so it is dropped for long time):

Drop JFS filesystem.

We have too many filesystems. We support 4 full-featured journalled 
local filesystems (ext3, reiserfs3, XFS and JFS) currently and 
new ones are appearing (reiser4, ext4?).

ext3 and reiserfs3 both are solid filesystems with good performance. 
For special applications, you might need better scalability or 
special features support (e.g. DMAPI). JFS and XFS offer somewhat 
more here (than ext3 or reiserfs3). However, XFS performs a bit 
better, gets much more testing and is well supported from sgi. 
JFS has more issues and the support from IBM is not as good.

Thus, JFS should be dropped from the list of filesystems offered 
in the SLES10 installer and should be marked unsupported (unless 
IBM commits to eXternally supporting it).

It should be marked deprecated in the release notes of SLES10 
and dropped for SLES11.

Note that SUSE Linux 9.3 already does not support JFS in YaST and 
mentions this in the release notes.

(In reply to Josef Reidinger from comment #11)
> JFS drop is old feature number 2105 ( sorry private only as it is really
> ancient ).
> 
> Quoting from it (not all info is up to date, consider that it is 11 years
> old, so it is dropped for long time):

Mounting and installing on JFS file systems has been working up until 42.3, no problems. 

> JFS has more issues and the support from IBM is not as good.

I submit there are no current issues with JFS and developer support is excellent. I ran into a minor fstrim issue only a week ago and had a patch within 70minutes. 

> Note that SUSE Linux 9.3 already does not support JFS in YaST and 
> mentions this in the release notes.

Like I said, mounting and installing JFS file systems has been working up until 42.3, no problems whatsoever.

reopening as I found that it is regression that storage-ng missing this feature: https://fate.suse.com/100401 ( basically allow to use unsupported filesystem )

Ok, so I will add this to the storage-ng list of pending tasks as an option in the expert partitioner to mount an existing filesystem of unsupported type.

Please, keep in mind that will not imply that such filesystems can be manipulated by YaST or that having an installation of Leap15 on top of JFS would be an scenario supported by the installer at all. We can't even guarantee (not under our control) that the Leap15 kernel will be able to deal with such filesystems.

Please, make sure that it's obvious that the FS is unsupported.

Moreover, I'm afraid, that Kernel in 15 might not include the JFS support
at all, so it might not work at the end, but a general "let's try" (confirmed
by user) could work.

Per, the point is, that we usually don't allow for unsupported scenarios
and as SLES, SLED etc. use the very same code, it might be considered as
bug if we allow using JFS and then it fails somewhere. I even think we have
a feature request that says: Do not allow ...

Anyway, let's try.

(In reply to Ancor Gonzalez Sosa from comment #14)
> Ok, so I will add this to the storage-ng list of pending tasks as an option
> in the expert partitioner to mount an existing filesystem of unsupported
> type.
> 
> Please, keep in mind that will not imply that such filesystems can be
> manipulated by YaST 

Understood. That's how it's been since almost 10 years. (for JFS). 

> or that having an installation of Leap15 on top of JFS
> would be an scenario supported by the installer at all. 

Ditto. 

> We can't even guarantee (not under our control) that the Leap15 kernel will 
> be able to deal with such filesystems.

Understood. 

From my point of view, I am happy as long as I can mount a JFS file system during the install.

(In reply to Lukas Ocilka from comment #15)
> Please, make sure that it's obvious that the FS is unsupported.
> 

I completely accept that, I'm happy to add that here. 

> Moreover, I'm afraid, that Kernel in 15 might not include the JFS support
> at all, so it might not work at the end, but a general "let's try" (confirmed
> by user) could work.

That would of course be a problem, I hope noone is so small-minded to want to exclude a file-system module from the kernel.  (unless it's coming from kernel upstream). 

> Per, the point is, that we usually don't allow for unsupported scenarios
> and as SLES, SLED etc. use the very same code, it might be considered as
> bug if we allow using JFS and then it fails somewhere. I even think we have
> a feature request that says: Do not allow ...
> 
> Anyway, let's try.

Lukas, thanks for explaining it, I appreciate it.  I do understand you guys have a different point of view to work with.

I updated the status to fit our search filters. This task is still queued in the YaST Team backlog.