Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a iSCSI target on a customer place I'm using from an old Fedora (Core6) server. I configured it and formatted as ext3 (mistake, now I know) and I've been working with it for some time.

Now I need to access this volume from other machine. As far as I've read, I can't do it safely from two machines at the same time (yep, that's the first thing I tried). So I've umount it from original server and tried to mount it on the new server (I did it at first with Ubuntu 10 LTS but when I was unable to do it I installed another Fedora with the same configuration) with no success.

The problem: I can see all target on NAS but when I do a "fdisk -l" to see all devices and know which mount I see all targets as SFS filesystem. From the original server I see all SFS (after all, they belong to my customer and don't know what he have in) except the one I manage which I see as 'Linux'.

Here it is the partition table as seen in the server (Fedora) which see it right. Spanish language, sorry. I hope it can be understood. My comments between [...]

[.. at beginning the real local drive ..]

Disco /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cilindros of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000080

Disposit. Inicio    Comienzo      Fin      Bloques  Id  Sistema
/dev/sda1               1          26      204800   83  Linux
/dev/sda2              26        6400    51200000   83  Linux
[.. more local partitions ..]

[... then iSCSI drives ...]

Disposit. Inicio    Comienzo      Fin      Bloques  Id  Sistema
/dev/sdc1               1      130541  1048570551   42  SFS

Disco /dev/sdf: 2147.5 GB, 2147483649024 bytes
255 heads, 63 sectors/track, 261083 cylinders 
Units = cilindros of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x2257d76f


[..... Other devices in between, and here it is the one I mind .....]

Disco /dev/sde: 2147.5 GB, 2147483648000 bytes
255 heads, 63 sectors/track, 261083 cylinders 
Units = cilindros of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 262144 bytes 
Disk identifier: 0x93afd446

Disposit. Inicio    Comienzo      Fin      Bloques  Id  Sistema
/dev/sde1               1      261083  2097149166   83  Linux  


[ .... and ever more devices ....]

On the machine I'm trying to configure, the one which should access the drive (but don't) I see the offending target as:

[....]

Disk /dev/sdc: 2147.4 GB, 2147483649024 bytes
255 heads, 63 sectors/track, 261083 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1               1      261083  2097149166   42  SFS


[....]

And I see rest of targets as SFS, the same as in first case.

Thank you in advanced,

share|improve this question
    
Please post the output from fdisk -l so that we could see that the target in question is not visible. What's your iSCSI target? Am I correct that Fedora is an initiator in terms of iSCSI topology and the target is exported by some other device? –  Dmitri Chubarov Oct 27 '12 at 6:02
    
Hi Dmitri, I've just add the fdisk -l output on both machines. And right: Old Fedora (whoch works) and new Ubuntu (don't work) and both initiators. Targets are on a NAS device but don't know the brand and model but almost sure a QNap. Thank you! –  jmiguel.rodriguez Oct 29 '12 at 10:20
add comment

2 Answers

fdisk reported labels don't mean much nowadays -- in fact as MS-DOS partition tables fall out of use, it even can be entirely misleading. If you want to know what's on a partition, better use file -s /dev/sdXX:

 file -s /dev/sda1
/dev/sda1: Linux rev 1.0 ext2 filesystem data (mounted or unclean), UUID=ebf12615-9c1a-4aca-9111-bebd1eaf4ed3 (large files)
file -s /dev/sda3
/dev/sda3: Linux rev 1.0 ext4 filesystem data, UUID=7322a490-8814-4f0b-92a7-a6f4287acadc (needs journal recovery) (extents) (large files) (huge files)
share|improve this answer
    
Didn't knew that, thank you wazoox for your info. Anyway, I can't access iSCSI target as file command reports it as 'data' so cannot mount it. Any hint? –  jmiguel.rodriguez Oct 30 '12 at 8:31
    
@jmiguel.rodriguez, this is definitely strange. What are you exporting from the iSCSI target? is it a fileIO or a blockIO device? You should give more details on the target type (lio, iet, tgt; etc) and configuration. –  wazoox Oct 30 '12 at 12:39
2  
I never knew about file -s... That would have come in handy recently! My current method of discovering the file system is with blkid. eg. /dev/sda1: UUID="c7f00876-a631-41c4-bf78-4cd18cce4041" TYPE="ext3" –  Soviero Oct 30 '12 at 12:50
    
Well, "file" has the advantage of working for about anything, block devices, media files, etc :) –  wazoox Oct 31 '12 at 17:32
add comment

SFS (0x42) partition type in fdisk -l output may be a sign of a partition that existed before it was formatted as ext3.

According to Wikipedia this partition type may correspond to Windows 2000/XP dynamic volume. If the partition was simply reformatted as EXT3, the type code could be left unchanged.

In order to check what partition type is there you could issue

TMPFILE=$(mktemp --tmpdir=/tmp) 
dd if=/dev/sdc1 bs=512 count=2048 of=$TMPFILE
file $TMPFILE
rm $TMPFILE

on a ext4 filesystem, for example, this sequence would produce

2048+0 records in
2048+0 records out
1048576 bytes (1.0 MB) copied, 0.0291348 s, 36.0 MB/s
/tmp/tmp.QLD5XhZOYn: Linux rev 1.0 ext4 filesystem data (needs journal recovery)
(extents) (large files) (huge files)

That indicates that whatever the partition type specified in the partition table, the partition itself is an EXT4. One Megabyte is usually enough to identify the true partition type.

If /dev/sdc1 indeed is an EXT3 partition as you expect, you could mount it safely. I would suggest though to mount it via Device Mapper multipath mount point to avoid problems if the device enumeration over iSCSI changes.

share|improve this answer
1  
Good point. Thank you. I've tested it, and on first machine (where it's well mounted): [root@scancia ~]# file /tmp/test /tmp/test: Linux rev 1.0 ext4 filesystem data (needs journal recovery) (extents) (large files) (huge files) On second machine (SFS system): [root@scanciaprodj2ee ~]# file /tmp/test /tmp/test: data So.. bad news. :-( I'll look the multipath parameter you mention, I presume it will solve the problem I also have (althouth didn't mind a lot) with /dev/sd?1 names on every reboot. –  jmiguel.rodriguez Oct 29 '12 at 18:15
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.