[weblacky]

Callahan, please re-read my post.

I physically tried this last year, 2019. I tried xfs versions 1 & 2, both will be recognized as xfs in linux but have major errors (null this and can’t find super block that) that will prevent mounting. The error I physically got was that current xfs-progs only supports version 3 or higher.

So yes, I did test it, that’s why I gave specifics, and as I mentioned I don’t know when they took the old support out. It was in there when xfs was introduced in Linux and Linux can still read SGI disk label partition formats.

I was shocked at my finding! Why leave in the rest of the SGI support without any read (let alone write) support in the current xfs tools.

As I mentioned, I only tried parted magic distributions, it if it’s not in parted magic, then I’d assume the support is not standard anymore. That’s why I said you could try to load a 10+ year old Linux to try to get back xfs support for early versions.

I believe EFS Linux support is still good.

[callahan]

Wow. All you said was that you "looked into it" which could mean many different things. No need for the snarky reply.

Why are so many in this community so toxic?

[Raion]

Easy guys, let's curb the acerbic replies on both sides.

I don't really notice anything snarky in the reply from Weblacky, but I would ask both of you to step away if we can't have professional discussions.

Regarding what Weblacky said, it does seem to have a basis in fact. The XFS FAQ here:

https://xfs.org/index.php/XFS_FAQ#Q:_Why...ided.3F.22

Indicates that there's differences in the versions of XFS.

Looking into the commit log, it does appear XFSProgs and associated XFS code has deprecated and removed functionality for V1, and likely other legacy systems:

https://fossies.org/linux/xfsprogs/doc/CHANGES

Regardless, I think we can all agree that physically transplanting a disk is not the best option for doing any transfer. You have NFSv3, FTP, and a few other methods that work just fine, especially with the associating complications.

Let's not devolve ourselves into incivility over miscommunications.

[callahan]

One use case I have right now is a dead HD in an Indigo2 that I have a full xfsdump for.

Linux support would allow me to easily image a drive on a test bench that I could then swap into the I2. So figuring out what might make this possible is interesting to me.

It could also make sense for historical preservation. For example dd'ing a drive from a production system that has who knows what potentially usefully software before turning the computer into a hobbyist system.

Agree this doesn't make sense for copying the odd file (or many files) off a working system. But as our systems age, any workaround that increases data availability and restore options is potentially helpful.

[Raion]

Indeed, there's just a few issues that the broken xfsprogs/xfs code implicates:

1. We're stuck at 2013-era or before Linux distros and pre-3.2 XFSProgs if I read the commit changes right.
2. XFSProgs is the mounting/fsck/repair utils for XFS, so there's not any alternatives I'm aware of that can work.

That all said, this SCSI-era stuff is all old stuff that doesn't usually work on modern machines, so as long as we know of old Linux distros that still work with package management etc that is probably the most reliable/pragmatic way.

[weblacky]

Also since, Irix doesn’t support any loopback image mounting (which I always felt was a real oversight given what xfs was trying to become) your shortest path would be relying on the fact that a restored file system doesn’t normally need to be correctly sized to a volume or partition that is larger than it’s original volume or partition.

Just get a larger disk, use Irix to create the partition / volume layout, then use Irix tools to xfsrestore into the main data partition.

As long as you have more room than you need, I don’t see why it won’t work. All the file systems I’ve worked with so far work just fine even when undersized for the disk they have been restored to, as long as they start correctly at the beginning of the partition/volume where the magic number identification can take place.

You should still be able to read it and pick through the data, I just wouldn’t attempt filesystem repairs in case the utilities in Irix attempt to resize the underlying xfs file system to the large partition/volume.


Also, I’ll put this out there, situations like these seem to walk a fine line between the utility of keeping the xfs format instead of using tar archives.

I’d recommend (for future use) only doing xfs backups that need to preserve filesystem properties on restore (user IDs, acls, xfs Metadata, or bootablity).

Otherwise, if the backup had been done using tar, then you could have opened it on many platforms and picked out the files you wanted.

I’ve learned the hard way that’s while you think a platform is going to be supported, it’s later removed and now it’s more work than you expected.

Consider just xfsrestore and then tarballing everything. Then you can look through your tarball on whatever platform/software you feel comfortable with.

[Raion]

Depressingly, I once looked into updating the XFS version that IRIX uses, but the code, even from 2004-ish doesn't compile on IRIX because it's looking for Linux-kernel specific things. Basically, without a major rework of it, you can't backport any fixes of XFS to IRIX. This is a tragedy, but since RedHat has basically dominated everything in Linux I'm very much not surprised.

[jan-jaap]

This thread went pretty far off topic, focusing on attaching the disk to a probably non-existing SCSI controller in a Linux PC the OP never claimed he had.

Back to the original question:

I am brand new to the SGI hobbyist computer and I just got my first SGI workstation. It is an Indy. I am wondering how I can transfer files between the Indy and my PC. Obviously it doesn't have USB ports, so flash drives aren't an option. I also don't have a floptical drive or a 3.5 inch floppy dirve installed. Can you hook the workstation to a PC using an ethernet cable and then somehow transfer files that way? If so, how would I go about that? What would I need to do?

Yes, you can transfer files using a direct ethernet connection. Most IRIX systems don't use DHCP so you may have to configure the system to use a fixed IP addresses in your LAN address range. By default an IRIX system will run an FTP server, and Windows still comes with an FTP client. So you can ftp into the Indy and fetch files. Beware that FTP login to the root account doesn't work if the root account doesn't have a password set.

Are there any other ways of transferring files? Please let me know. Thanks.

Use a NAS. Doesn't everybody have one? Share a volume using both NFS and SMB protocols. The Indy talks NFS, the PC (or Mac) talk SMB. Problem solved.

[callahan]

For those who stumble across this post, there is an update with instructions for at least XFS v2 volumes here: https://forums.irixnet.org/thread-3301-p...l#pid23565

[defaultrouteuk]

@Raion is gonna hate this because NFS mounts that don't exist will cause you headaches....

Anyway FWIW I found that the easiest method for me (YMMV) was to use a NAS as a man in the middle (Synology, OpenNAS, FreeNAS etc will work).

1) Use a simple switch to attach you WINDOWS box, SGI and NAS. (probably your home router will have a bunch of ports)
2) Create a volume on your NAS and share it using NFS and Windows (CIFS/Samba etc)
3) Mount the volume on the SGI / Map the volume on Windows
4) Sit back and enjoy how easy that was. Drag and drop files and see the miracle of networking.

SFTP however was the most accessible method as most have pointed out. It works (out of the box) and I'd recommend FileZilla on Windows (or Cyberduck on a Mac).

Best wishes to all
Richie