PSARC/2009/453 - futimens, utimensat
Roger A. Faulkner Roger.Faulkner at sun.com wrote: IIRC, then the pcfs timestamps have a 2 second timestamp granularity for the mtime and a one day granularity for the atime. The latter cannot be represented in the pathconf() fcall. J?rg Yeah, well... I just made pathconf(_PC_TIMESTAMP_RESOLUTION) return 1000 000 000 for pcfs. Is that good enough? Does anyone really care? Should I make it fail (-1 w/ EINVAL)? Star and cpio decide on the timestamp whether a file will be extracted or not. If pathconf(_PC_TIMESTAMP_RESOLUTION) returns 1000 000 000, star will probably make a wrong decision in future because a timestamp of 1000 may be a rounded down 1001. Star currently implements some heuristics but in case that pathconf(_PC_TIMESTAMP_RESOLUTION) will work, future versions will asume that the returned value is correct. 2 seconds may be represented by a 32 bit value. BTW: POSIX requires pathconf(_PC_TIMESTAMP_RESOLUTION) to return -1/EOVERFLOW in case of an number overflow. We would need to do this if we look at atime. I however tend to believe it is better not to return an overflow as mtime is more important than atime. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de(uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Transport Layer Retries (TLR) Support (PSARC/2009/461 FastTrack Timeout 09/02/20009)
Hi, The SAS1and SAS2 Spec don't explicitly tell how many retries it should perform, but it's not a reasonable implementation to retry forever. Because that is a mechanism between Firmware and Tape, I've asked LSI to see if they can provide any numbers. For the worst case, if it retried too many times, the driver has the timeout mechanism to handle that. Garrett D'Amore wrote: Jianfei Wang wrote: 3) Does the above have any ramifications for FMA? Because the firmware would deal with TLR work, it would handle the error, the error is transparent for system, it doesn't report any message to FMA module. Will it eventually give up, or will it keep retrying the command forever? How many retries will it perform? - Garrett
Transport Layer Retries (TLR) Support (PSARC/2009/461 FastTrack Timeout 09/02/20009)
Hi Randy, This project focuses on negotiating and setting the TLR control bit through the driver interaction. The TLR operation is done at the firmware level, not the driver level. So question 1, 2, 4 and 5 are not in the scope of this project. For question 3, SAS1 doesn't support TLR when MPXIO is enabled. This is specified in document 07-027r2 (SAS-2 Enabling and disabling Transport Layer Retries) on T10. The SAS1 TLR mode sense/mode select has been proved to be impractical when MPXIO is enabled, and the reason is ' If the mode page is shared, then it's possible that multiple initiators don?t agree on the setting interfere with each other. This is less of a problem if the mode page is per I_T nexus, but such implementations are rare.' The protocol author found mode sense/mode select is a bad support way, so SAS1 TLR support is abandoned when MPXIO is enabled. SAS2 inquiries the VPD page to support TLR, it would support MPXIO. Best Regards Jianfei Wang Frank Che wrote: Some questions from Randy on this project: 1) How will this both work with command recovery that is in Nevada and doesn't exsist in previous versions of Solaris where it is not? 2) This looks like it expects the tape driver to be the only source of resets. With MPxIO enabled scsi_vhci can do resets when failing over paths that would not have originated from the target driver. Some HBA's also initiate resets on their own. 3) If MPxIO is enabled, the scsi_ifgetcap(9F) would not get the capability from the HBA and therefor would not do the mode sense/mode select correctly. See bug 6755363 as this would also effect SCSI_CAP_TRAN_LAYER_RETRIES. 4) How will this work with ComStar where the transport may not be as obvious to the target driver. 5) Does TLR give up? If a connection fails in a MPxIO invironment waiting for a connection to reconnect would prevent failing over. Also in a non-MPxIO environment not waiting could cause a failure that could otherwise could be recovered when reconnected. Frank. Frank Che wrote: I'm sponsoring this case for Jianfei Wang. The timer is set for 09/02/2009. -Frank. 1. Introduction 1.1. Project/Component Working Name: Transport Layer Retries (TLR) Support 1.2. Name of Document Author/Supplier: Author: Jianfei Wang 1.3. Date of This Document: 08/24/2009 4. Technical Description: 4.1. Summary This project is to provide TLR (Transport Layer Retries) support in Solaris so that tape drive devices could be better supported. Requested release binding is Patch/Micro. 4.2. Details To support Transport Layer Retries(TLR), a new SCSI transport capability, SCSI_CAP_TRAN_LAYER_RETRIES, will be added. HBA drivers need TLR support should be updated to know this capability. The storage target driver should also be updated to coordinate the TLR support. When a new tape drive device is detected, the target driver checks the HBA's capability of TLR support with the scsi_ifgetcap(9F) interface in the attach(9E) entry point. The target driver reads Vital Product Data (VPD) page 0x90 to get the target device type. If VPD page 0x90 exists, the target device type is SAS2; otherwise the target device type is SAS1. If the HBA supports TLR and the target device is a SAS1 device, then the target driver uses SCSI command MODE_SENSE and MODE_SELECT to set the mode page (Protocol-Specific Logical Unit mode page)'s TLR flag. If set successfully, Initiator_Target_Lun nexus support TLR property. Because the mode page is not persistent, the TLR flag bit will be lost when the target device do a hard reset. So the target driver needs to set the mode page's TLR flag each time the target device completes hard reset. If the HBA supports TLR and the target device is SAS2 device, then the target driver issues InquiryVPD to get the capability of the tape device to check whether the target device is able to support TLR. If both the HBA driver and the tape device support TLR, the target driver will send a commands packet with a special pkg_flag, FLAG_TLR, to notify the HBA driver to set TLR in control bit before transportation. If the Initiator_Target_Lun nexus does not support TLR, commands from the target driver to the HBA driver would fail and the pkt_reason will be set to CMD_TLR_OFF. When the target driver get this reason, it will turn off the TLR control. 4.3. Exported Interfaces Interface Commitment Comments = == = SCSI_CAP_TRAN_LAYER_RETRIES Committed SCSI TLR capability tran-layer-retries Committed SCSI_CAP_ASCII content FLAG_TLR Committed pkg_flag indicating TLR is supported CMD_TLR_OFF Committed pkt_reason indicating TLR is not supported 4.4. Bug/RFE Number(s) 6647764 - Solaris storage driver Transport Layer Retries (TLR) support 4.5. References Serial Attached SCSI - 1.1 (SAS-1.1) Serial Attached SCSI - 2 (SAS-2) SCSI Primary Commands - 4 (SPC-4) http://www.t10.org/
Offline attribute [PSARC/2009/464 FastTrack timeout 09/02/2009]
On 08/27/09 03:50, Joerg Barfurth wrote: Alan M Wright schrieb: [...] SAMFS already has something like this but it is a private interface. This case is intended to make an offline bit available as a generic, public interface. This is at odds with your Exported Interfaces table, which indicates that all new interfaces are introduced as 'Consolidation Private'. I was referring to ls(1), chmod(1) and fgetattr(3C). A_OFFLINE and XAT_OFFLINE attributes consolidation private. Alan
Offline attribute [PSARC/2009/464 FastTrack timeout 09/02/2009]
On 08/27/09 13:17, Dean Roehrich wrote: On Wed, Aug 26, 2009 at 04:40:41PM -0700, Alan M Wright wrote: On 08/26/09 14:33, Dean Roehrich wrote: On Wed, Aug 26, 2009 at 09:55:20AM -0600, Tim Haley wrote: The offline attribute (XAT_OFFLINE) will be added to the read- write system attributes view defined in PSARC/2007/315 and will be generally available to file systems and applications to indicate the offline/online status of objects: boolean value of true indicates the object is offline. In order to set or clear the offline attribute the consumer must have the ACE_WRITE_ATTRIBUTES permission or the PRIV_FILE_OWNER privilege. In the kernel, it will be accessible via VOP_GETATTR() and VOP_SETATTR(). In user space, it will be accessible via chmod(1), ls(1) and fgetattr(3C). No changes are required to the VOP or fgetattr(3C) function prototypes. An HSM does not want the file's owner to twiddle this status. That status should be controlled by the HSM. The file system can return EACCES or EPERM if it doesn't want the attribute changed via fsetattr(3C). I didn't want to preclude user space applications from being able to manipulate this attribute on regular (non-HSM) file systems. As I mentioned, a virus scanner could be configured to mark the file as offline while it is performing a scan-on- open. In that case, how would the virus scanner and the HSM interoperate on the same filesystem? I think that's outside the scope of this case - that would be a design consideration for those components. And there's already a potential interaction problem between virus scanning and HSM: virus scanners may keep pulling files onto primary storage if poorly configured. Perhaps a well-designed virus scanner would recognize when the offline bit is already set and not attempt to scan files during background/scheduled scanning, and perhaps it's a bad idea for a virus scanner to manipulate the offline bit. Hopefully, these are application specific design problems that we have to solve here. Given your use-case, how would an HSM know when it can trust or use this bit? If an HSM is managing the offline bit it can simply return EPERM if anything external to the HSM tries to change the state of that attribute. Nothing here requires that a file system or HSM allow the offline attribute to be changed outside of its control. Alan
Offline attribute [PSARC/2009/464 FastTrack timeout 09/02/2009]
On 08/28/09 01:42, Alan M Wright wrote: On 08/27/09 13:17, Dean Roehrich wrote: On Wed, Aug 26, 2009 at 04:40:41PM -0700, Alan M Wright wrote: On 08/26/09 14:33, Dean Roehrich wrote: On Wed, Aug 26, 2009 at 09:55:20AM -0600, Tim Haley wrote: The offline attribute (XAT_OFFLINE) will be added to the read- write system attributes view defined in PSARC/2007/315 and will be generally available to file systems and applications to indicate the offline/online status of objects: boolean value of true indicates the object is offline. In order to set or clear the offline attribute the consumer must have the ACE_WRITE_ATTRIBUTES permission or the PRIV_FILE_OWNER privilege. In the kernel, it will be accessible via VOP_GETATTR() and VOP_SETATTR(). In user space, it will be accessible via chmod(1), ls(1) and fgetattr(3C). No changes are required to the VOP or fgetattr(3C) function prototypes. An HSM does not want the file's owner to twiddle this status. That status should be controlled by the HSM. The file system can return EACCES or EPERM if it doesn't want the attribute changed via fsetattr(3C). I didn't want to preclude user space applications from being able to manipulate this attribute on regular (non-HSM) file systems. As I mentioned, a virus scanner could be configured to mark the file as offline while it is performing a scan-on- open. In that case, how would the virus scanner and the HSM interoperate on the same filesystem? I think that's outside the scope of this case - that would be a design consideration for those components. And there's already a potential interaction problem between virus scanning and HSM: virus scanners may keep pulling files onto primary storage if poorly configured. Perhaps a well-designed virus scanner would recognize when the offline bit is already set and not attempt to scan files during background/scheduled scanning, and perhaps it's a bad idea for a virus scanner to manipulate the offline bit. Hopefully, these are application specific design problems that we have to solve here. Sorry, Hopefully, these are application specific design problems that we _don't_ have to solve here. Alan Given your use-case, how would an HSM know when it can trust or use this bit? If an HSM is managing the offline bit it can simply return EPERM if anything external to the HSM tries to change the state of that attribute. Nothing here requires that a file system or HSM allow the offline attribute to be changed outside of its control. Alan
Minor update ABE share property for NFS and SMB [PSARC/2009/375 Self Review]
Attached is a minor update to this already closed case. I'm submitting this on behalf of the project team since their original sponsor isn't available to do so at the moment. The update is to not use ABE for NFS only CIFS. I don't believe that this change causes the case to need to be re-opened to run with a timer. -- Darren J Moffat -- next part -- An embedded and charset-unspecified text was scrubbed... Name: abe_diff.txt URL: http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20090828/96a78c80/attachment.txt -- next part -- An embedded and charset-unspecified text was scrubbed... Name: abe_smb.txt URL: http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20090828/96a78c80/attachment-0001.txt
Transport Layer Retries (TLR) Support (PSARC/2009/461 FastTrack Timeout 09/02/20009)
Hi Milan, No, TLR only take effects when there are transport layer errors(lost frame), the protocol will retransmit the lost frame automatically to recover. It has no side effects when there is no error occurs. So that's a value-add feature and there is no reason to disable it if both HBA and Tape support it. Best Regards Jianfei Wang Milan Jurik wrote: Hi, Jianfei Wang p??e v ?t 27. 08. 2009 v 18:29 +0800: [...] 2) As I'm not one of the people familiar with TLR, I'd like to better understand what this does to failure modes. Specifically, what does TLR do when a SCSI error is encountered? Can it lead to an interminable hang-like condition where the transport driver continues retrying a failed SCSI command indefinitely? How the retransmission happen are specified in the TLR documents (SAS1R10 and SAS2R16). This transmission is handled in the firmware of the HBA and tape device, according to the SAS specification, not in the HBA driver or the target driver. That's why this document focuses on the negotiation process. Once the negotiation is done, everything else is performed through the firmware. Any documented way to disable negotiation of this feature by administrator? Best regards, Milan
Offline attribute [PSARC/2009/464 FastTrack timeout 09/02/2009]
On Fri, Aug 28, 2009 at 01:42:39AM -0700, Alan M Wright wrote: On 08/27/09 13:17, Dean Roehrich wrote: On Wed, Aug 26, 2009 at 04:40:41PM -0700, Alan M Wright wrote: On 08/26/09 14:33, Dean Roehrich wrote: On Wed, Aug 26, 2009 at 09:55:20AM -0600, Tim Haley wrote: The offline attribute (XAT_OFFLINE) will be added to the read- write system attributes view defined in PSARC/2007/315 and will be generally available to file systems and applications to indicate the offline/online status of objects: boolean value of true indicates the object is offline. In order to set or clear the offline attribute the consumer must have the ACE_WRITE_ATTRIBUTES permission or the PRIV_FILE_OWNER privilege. In the kernel, it will be accessible via VOP_GETATTR() and VOP_SETATTR(). In user space, it will be accessible via chmod(1), ls(1) and fgetattr(3C). No changes are required to the VOP or fgetattr(3C) function prototypes. An HSM does not want the file's owner to twiddle this status. That status should be controlled by the HSM. The file system can return EACCES or EPERM if it doesn't want the attribute changed via fsetattr(3C). I didn't want to preclude user space applications from being able to manipulate this attribute on regular (non-HSM) file systems. As I mentioned, a virus scanner could be configured to mark the file as offline while it is performing a scan-on- open. In that case, how would the virus scanner and the HSM interoperate on the same filesystem? I think that's outside the scope of this case - that would be a design consideration for those components. And there's already a potential interaction problem between virus scanning and HSM: virus scanners may keep pulling files onto primary storage if poorly configured. Perhaps a well-designed virus scanner would recognize when the offline bit is already set and not attempt to scan files during background/scheduled scanning, and perhaps it's a bad idea for a virus scanner to manipulate the offline bit. Hopefully, these are application specific design problems that we have to solve here. Given your use-case, how would an HSM know when it can trust or use this bit? If an HSM is managing the offline bit it can simply return EPERM if anything external to the HSM tries to change the state of that attribute. Nothing here requires that a file system or HSM allow the offline attribute to be changed outside of its control. Customers will write applications (maybe a file browser) which query this bit, and they'll file bugs against the HSM products for not setting it. The HSM products will then be in a bind because they know they can't use it as specified (at a minimum, they would have to modify fsetattr to no longer allow the setting of that bit, which would break some other customer's home-grown application...and so it goes). So here's how this case _could_ have been presented, given that it's supposed to displace PSARC/2009/381: You introduce XAT_OFFLINE, which is owned by the HSM. The virus scanner must honor this bit and avoid scanning offline files (there, now your virus scanner won't screw up the HSM resource management policy). Dean
Transport Layer Retries (TLR) Support (PSARC/2009/461 FastTrack Timeout 09/02/20009)
Jianfei Wang wrote: Hi Randy, This project focuses on negotiating and setting the TLR control bit through the driver interaction. The TLR operation is done at the firmware level, not the driver level. So question 1, 2, 4 and 5 are not in the scope of this project. When MPxIO was implemented it was tested with multi port SAS drives. For question 3, SAS1 doesn't support TLR when MPXIO is enabled. This is specified in document 07-027r2 (SAS-2 Enabling and disabling Transport Layer Retries) on T10. The SAS1 TLR mode sense/mode select has been proved to be impractical when MPXIO is enabled, and the reason is ' If the mode page is shared, then it's possible that multiple initiators don?t agree on the setting interfere with each other. This is less of a problem if the mode page is per I_T nexus, but such implementations are rare.' The protocol author found mode sense/mode select is a bad support way, so SAS1 TLR support is abandoned when MPXIO is enabled. SAS2 inquiries the VPD page to support TLR, it would support MPXIO. Tape drives are explicitly one user at at time so doing mode sense mode select on open (reservation) and on detected resets should not be an issue. Can the target driver determine if the drive supports TLR by reading the mode sense page? All of this will work if the target driver can detect if TLR is supported without the scsi_getcap() and if the HBA does not attempt to recover a single command forever. Best Regards Jianfei Wang Frank Che wrote: Some questions from Randy on this project: 1) How will this both work with command recovery that is in Nevada and doesn't exsist in previous versions of Solaris where it is not? 2) This looks like it expects the tape driver to be the only source of resets. With MPxIO enabled scsi_vhci can do resets when failing over paths that would not have originated from the target driver. Some HBA's also initiate resets on their own. 3) If MPxIO is enabled, the scsi_ifgetcap(9F) would not get the capability from the HBA and therefor would not do the mode sense/mode select correctly. See bug 6755363 as this would also effect SCSI_CAP_TRAN_LAYER_RETRIES. 4) How will this work with ComStar where the transport may not be as obvious to the target driver. 5) Does TLR give up? If a connection fails in a MPxIO invironment waiting for a connection to reconnect would prevent failing over. Also in a non-MPxIO environment not waiting could cause a failure that could otherwise could be recovered when reconnected. Frank. Frank Che wrote: I'm sponsoring this case for Jianfei Wang. The timer is set for 09/02/2009. -Frank. 1. Introduction 1.1. Project/Component Working Name: Transport Layer Retries (TLR) Support 1.2. Name of Document Author/Supplier: Author: Jianfei Wang 1.3. Date of This Document: 08/24/2009 4. Technical Description: 4.1. Summary This project is to provide TLR (Transport Layer Retries) support in Solaris so that tape drive devices could be better supported. Requested release binding is Patch/Micro. 4.2. Details To support Transport Layer Retries(TLR), a new SCSI transport capability, SCSI_CAP_TRAN_LAYER_RETRIES, will be added. HBA drivers need TLR support should be updated to know this capability. The storage target driver should also be updated to coordinate the TLR support. When a new tape drive device is detected, the target driver checks the HBA's capability of TLR support with the scsi_ifgetcap(9F) interface in the attach(9E) entry point. The target driver reads Vital Product Data (VPD) page 0x90 to get the target device type. If VPD page 0x90 exists, the target device type is SAS2; otherwise the target device type is SAS1. If the HBA supports TLR and the target device is a SAS1 device, then the target driver uses SCSI command MODE_SENSE and MODE_SELECT to set the mode page (Protocol-Specific Logical Unit mode page)'s TLR flag. If set successfully, Initiator_Target_Lun nexus support TLR property. Because the mode page is not persistent, the TLR flag bit will be lost when the target device do a hard reset. So the target driver needs to set the mode page's TLR flag each time the target device completes hard reset. If the HBA supports TLR and the target device is SAS2 device, then the target driver issues InquiryVPD to get the capability of the tape device to check whether the target device is able to support TLR. If both the HBA driver and the tape device support TLR, the target driver will send a commands packet with a special pkg_flag, FLAG_TLR, to notify the HBA driver to set TLR in control bit before transportation. If the Initiator_Target_Lun nexus does not support TLR, commands from the target driver to the HBA driver would fail and the pkt_reason will be set to CMD_TLR_OFF. When the target driver get this reason, it will turn off the TLR control. 4.3. Exported Interfaces Interface Commitment Comments
Offline attribute [PSARC/2009/464 FastTrack timeout 09/02/2009]
On 08/28/09 07:24, Dean Roehrich wrote: On Fri, Aug 28, 2009 at 01:42:39AM -0700, Alan M Wright wrote: On 08/27/09 13:17, Dean Roehrich wrote: On Wed, Aug 26, 2009 at 04:40:41PM -0700, Alan M Wright wrote: On 08/26/09 14:33, Dean Roehrich wrote: On Wed, Aug 26, 2009 at 09:55:20AM -0600, Tim Haley wrote: The offline attribute (XAT_OFFLINE) will be added to the read- write system attributes view defined in PSARC/2007/315 and will be generally available to file systems and applications to indicate the offline/online status of objects: boolean value of true indicates the object is offline. In order to set or clear the offline attribute the consumer must have the ACE_WRITE_ATTRIBUTES permission or the PRIV_FILE_OWNER privilege. In the kernel, it will be accessible via VOP_GETATTR() and VOP_SETATTR(). In user space, it will be accessible via chmod(1), ls(1) and fgetattr(3C). No changes are required to the VOP or fgetattr(3C) function prototypes. An HSM does not want the file's owner to twiddle this status. That status should be controlled by the HSM. The file system can return EACCES or EPERM if it doesn't want the attribute changed via fsetattr(3C). I didn't want to preclude user space applications from being able to manipulate this attribute on regular (non-HSM) file systems. As I mentioned, a virus scanner could be configured to mark the file as offline while it is performing a scan-on- open. In that case, how would the virus scanner and the HSM interoperate on the same filesystem? I think that's outside the scope of this case - that would be a design consideration for those components. And there's already a potential interaction problem between virus scanning and HSM: virus scanners may keep pulling files onto primary storage if poorly configured. Perhaps a well-designed virus scanner would recognize when the offline bit is already set and not attempt to scan files during background/scheduled scanning, and perhaps it's a bad idea for a virus scanner to manipulate the offline bit. Hopefully, these are application specific design problems that we have to solve here. Given your use-case, how would an HSM know when it can trust or use this bit? If an HSM is managing the offline bit it can simply return EPERM if anything external to the HSM tries to change the state of that attribute. Nothing here requires that a file system or HSM allow the offline attribute to be changed outside of its control. Customers will write applications (maybe a file browser) which query this bit, and they'll file bugs against the HSM products for not setting it. And perhaps that's appropriate because this case is an action item from PSARC/2009/381 to introduce this attribute. The HSM products will then be in a bind because they know they can't use it as specified (at a minimum, they would have to modify fsetattr to no longer allow the setting of that bit, which would break some other customer's home-grown application...and so it goes). There is absolutely no need to modify fsetattr() in this way, and it would be wrong to apply or enforce policy in fsetattr(). fsetattr() is just a conduit. As I said previously, the HSM or file system can return EPERM. So here's how this case _could_ have been presented, given that it's supposed to displace PSARC/2009/381: This case is not displacing PSARC/2009/381. You introduce XAT_OFFLINE, which is owned by the HSM. The virus scanner must honor this bit and avoid scanning offline files (there, now your virus scanner won't screw up the HSM resource management policy). I think you're distracted by this hypothetical HSM/virus scanning interaction but it's not relevant here. An HSM or file system can easily reject attempts to manipulate the offline attribute. This is a non-issue. Alan
Fast reboot support of GNOME restart dialog [LSARC/2009/454 FastTrack timeout 09/01/2009]
On Thu, 27 Aug 2009, Jedy Wang wrote: On Thu, 2009-08-27 at 02:54 -0700, Alan Coopersmith wrote: Jedy Wang wrote: Sorry if it wasn't clear, but as I see it, there is no need to check SMF and do something based on the result. Just reboot (or 'init 6'), and the right thing will occur. I don't see that an extra button to decide if fast or BIOS/Prom is necessary, as the vast majority of users either won't care or won't understand the difference (and the latter will only add to their confusion). Hi Randy, I do not think the option is not necessary. There are several student intents in the Desktop QE team who work on testing wondering how they can reboot to grub and enter another BE. So is it really a menu they want of BE's that the command should beactivate before rebooting, so they don't have to wait for the right moment to choose one in grub? Hi Alan, Or entering other OS. But yes, what you mentioned is on our todo list. Regards, Jedy I still see the problem as being: Need to boot something else, and not Fast reboot support (it is just that 'reboot -p' allows a mechanism for selecting something else). So if a different OS selection is on the todo list, then when that is available, this feature is obsolete. I suspect that efforts are more better directed at creating a way to select something else, and not expose the (potentiall) dirty details of how we get there. Cheers! Randy
nfs4_fid() [PSARC/2009/468 FastTrack timeout 09/04/2009]
I'm sponsoring this case for Bill Baker of the NFS team. This case proposed enabling technology for a forthcoming closed case. The timer expires on Friday, September 4, 2009. This case requests minor binding. Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: nfs4_fid() 1.2. Name of Document Author/Supplier: Author: Bill Baker 1.3 Date of This Document: 28 August, 2009 4. Technical Description Historically, the NFSv4 client has not implemented the VOP_FID() function due to fundamental limitations of the protocol. The client cannot construct a file identifier which can be used to reactivate a vnode (via VFS_VGET()) which is usable in all cases. In particular, volatile file handle recovery as well as handling VOP_OPEN() is impossible without the additional information which is created and maintained by the NFSv4 client during VOP_LOOKUP(). Vnodes activated via VFS_VGET() may not have this information, nor can it be constructed. Given these limitations, the current nfs4_fid() simply returns EREMOTE. However, having nfs4_fid() return a file id can be useful in a very narrow, controlled context. This file ID can be used as an opaque cookie which can be compared to file IDs from other vnodes from the same vfs. This could be used by a file tree walking program to determine if a newly looked up file had been discovered previously since, by definition, the file handle uniquely identifies a different file in the protocol. This ID is persistent (assuming the server is using persistent file handles) and is therefore durable and reliable across reboots of both the client and server. The consumer of this ID can write it to stable storage and safely recover its state even after a client reboot. Therefore, nfs4_fid() is reimplemented to return the client file handle from the rnode as a file ID, solely for the purpose of doing this equivalency comparison. nfs4_vget() will not honor this file ID, meaning that it can ONLY be used in this manner, it cannot be used to activate a vnode. Since this new behavior may expose existing subsystems, like cachefs, to new failure modes, nfs4_fid() will only return a file ID when the client file system is mounted with -o fid. By default, the option is off and the NFSv4 client will retain its current behavior. Ideally, this mount option is only used by system components which wish to use the file ID for identification as described above. Other uses are not supported. The option will NOT be documented, due to its limited utility. |Proposed |Specified | |Stability |in what| Interface Name |Classification |Document? | Comments === |Consolidation |This | -o fid|Private|Document | new option to | | | mount_nfs | | | 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open
[desktop-discuss] Fast reboot support of GNOME restart dialog [LSARC/2009/454 FastTrack timeout 09/01/2009]
Randy Fishel wrote: I still see the problem as being: Need to boot something else, and not Fast reboot support (it is just that 'reboot -p' allows a mechanism for selecting something else). So if a different OS selection is on the todo list, then when that is available, this feature is obsolete. I suspect that efforts are more better directed at creating a way to select something else, and not expose the (potentiall) dirty details of how we get there. I disagree, assuming you're implying that there should be no distinction made between a fast reboot and OS selection. As a user, there is a big difference between 'fast' reboot and a normal one. One completely resets my hardware and allows me access to the BIOS, the other does not. Finally, I also believe it would be wrong to assume that all of the other OS's you would want to boot to are present in the grub configuration for OpenSolaris. For example, on my system I use the boot drive selection feature of my BIOS to boot from a separate hard drive for OpenSolaris. The GRUB on that hard drive has no idea I have other hard drives or other operating systems. That is why I expect a distinction between 'Reboot' and 'Fast Reboot' explicitly. Cheers, -- Shawn Walker
nfs4_fid() [PSARC/2009/468 FastTrack timeout 09/04/2009]
On Fri, Aug 28, 2009 at 04:07:03PM -0500, Rich.Brown at Sun.COM wrote: However, having nfs4_fid() return a file id can be useful in a very narrow, controlled context. This file ID can be used as an opaque cookie which can be compared to file IDs from other vnodes from the same vfs. This could be used by a file tree walking program to determine if a newly looked up file had been discovered previously since, by definition, the file handle uniquely identifies a different file in the protocol. This ID is persistent (assuming the server is using persistent file handles) and is therefore durable and reliable That's a big assumption. There was a thread recently on nfs-discuss about adding server support for volatile file handles, for use with FUSE filesystems that lack persistent file IDs. I think that would be very useful. But even beyond that, volatile filehandles are in there to help cope with filesystems such as FAT, where no persistent file IDs exist, and so existing servers may very well be using volatile filehandles. across reboots of both the client and server. The consumer of this ID can write it to stable storage and safely recover its state even after a client reboot. Doesn't sound right to me. But then, this: Therefore, nfs4_fid() is reimplemented to return the client file handle from the rnode as a file ID, solely for the purpose of doing this equivalency comparison. nfs4_vget() will not honor this file ID, meaning that it can ONLY be used in this manner, it cannot be used to activate a vnode. limits the damage that one could do by persistently storing volatile FIDs. Since this new behavior may expose existing subsystems, like cachefs, to new failure modes, nfs4_fid() will only return a file ID when the client file system is mounted with -o fid. By default, the option is off and the NFSv4 client will retain its current behavior. Ideally, this mount option is only used by system components which wish to use the file ID for identification as described above. Other uses are not supported. The option will NOT be documented, due to its limited utility. It might be better if there was a way for the VOP to indicate that the returned FID is volatile. Maybe a pathconf that looks at the per-filesystem fh_expire_type attribute? Nico --
nfs4_fid() [PSARC/2009/468 FastTrack timeout 09/04/2009]
This interface will not return a volatile file handle, period, ever. Nicolas Williams wrote: On Fri, Aug 28, 2009 at 04:07:03PM -0500, Rich.Brown at Sun.COM wrote: However, having nfs4_fid() return a file id can be useful in a very narrow, controlled context. This file ID can be used as an opaque cookie which can be compared to file IDs from other vnodes from the same vfs. This could be used by a file tree walking program to determine if a newly looked up file had been discovered previously since, by definition, the file handle uniquely identifies a different file in the protocol. This ID is persistent (assuming the server is using persistent file handles) and is therefore durable and reliable That's a big assumption. There was a thread recently on nfs-discuss about adding server support for volatile file handles, for use with FUSE filesystems that lack persistent file IDs. I think that would be very useful. But even beyond that, volatile filehandles are in there to help cope with filesystems such as FAT, where no persistent file IDs exist, and so existing servers may very well be using volatile filehandles. across reboots of both the client and server. The consumer of this ID can write it to stable storage and safely recover its state even after a client reboot. Doesn't sound right to me. But then, this: Therefore, nfs4_fid() is reimplemented to return the client file handle from the rnode as a file ID, solely for the purpose of doing this equivalency comparison. nfs4_vget() will not honor this file ID, meaning that it can ONLY be used in this manner, it cannot be used to activate a vnode. limits the damage that one could do by persistently storing volatile FIDs. Since this new behavior may expose existing subsystems, like cachefs, to new failure modes, nfs4_fid() will only return a file ID when the client file system is mounted with -o fid. By default, the option is off and the NFSv4 client will retain its current behavior. Ideally, this mount option is only used by system components which wish to use the file ID for identification as described above. Other uses are not supported. The option will NOT be documented, due to its limited utility. It might be better if there was a way for the VOP to indicate that the returned FID is volatile. Maybe a pathconf that looks at the per-filesystem fh_expire_type attribute? Nico -- Bill Baker, 512-401-1081, x64081
2009/470 tcp_keepalive For inetd Services
I'm filing this case for Gary as closed-approved-automatic, as it seems an obvious extension to existing interface. As usual, speak up if you'd like to see it promoted to a fasttrack. liane --- tcp_keepalive For inetd Services Gary Mills 08/27/2009 1. Summary The inetd restarter defines a set of properties to control the behaviour of the services it manages. This case adds the option `tcp_keepalive' to the inetd restarter. Setting this option enables the TCP keepalive facility for connections to services managed by inetd. It's needed because some services do not have the ability to enable this facility by themselves. This property is set to false by default for inetd services, and the stability is Committed. 2. Manpage diffs *** inetd.OcatWed Aug 26 16:39:12 2009 --- inetd.catWed Aug 26 16:40:32 2009 *** *** 473,478 --- 473,487 set to true. + tcp_keepalive + + If true, enable the periodic transmission of messages on + a connected socket. If the connected party fails to + respond to these messages, the connection is con- + sidered broken. This applies only to services with + endpoint_type set to streams and wait set to false. + + tcp_trace If true, and this is a nowait-type service, inetd logs *** *** 566,571 --- 575,581 inherit_env true max_con_rate-1 max_copies -1 +tcp_keepalive false tcp_trace false tcp_wrappersfalse
Gutenprint Ver 5.2.4 [LSARC/2009/469 FastTrack timeout 09/04/2009]
I'm sponsoring this fast track case for Gowtham. Gutenprint is a newer version (and name change) of Gimp-print. Proposal FOSS checklist are attached. It almost qualifies for automatic approval except for this section in the FOSS checklist (which is hopefully OK): Are 64-bit versions of the libraries being delivered? [ ] Yes [X] No - ARC review required It is not possible to deliver 64-bit Gutenprint libraries. Gutenprint depends on cups, ghostscript and foomatic. Ghostscript and foomatic do not deliver 64-bit libraries. So, we cannot build 64-bit libraries and hence provide only the 32-bit libraries. -- Jim Gates Sun Microsystems Peterborough, NH, USA http://sun.com/postgresql -- next part -- An embedded and charset-unspecified text was scrubbed... Name: Gutenprint-Proposal.txt URL: http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20090828/d4d84390/attachment.txt -- next part -- An embedded and charset-unspecified text was scrubbed... Name: Gutenprint-FOSS-checklist.txt URL: http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20090828/d4d84390/attachment-0001.txt
2009/470 tcp_keepalive For inetd Services
Liane Praza wrote: I'm filing this case for Gary as closed-approved-automatic, as it seems an obvious extension to existing interface. As usual, speak up if you'd like to see it promoted to a fasttrack. +1, it seems obvious enough. - Garrett liane --- tcp_keepalive For inetd Services Gary Mills 08/27/2009 1. Summary The inetd restarter defines a set of properties to control the behaviour of the services it manages. This case adds the option `tcp_keepalive' to the inetd restarter. Setting this option enables the TCP keepalive facility for connections to services managed by inetd. It's needed because some services do not have the ability to enable this facility by themselves. This property is set to false by default for inetd services, and the stability is Committed. 2. Manpage diffs *** inetd.OcatWed Aug 26 16:39:12 2009 --- inetd.catWed Aug 26 16:40:32 2009 *** *** 473,478 --- 473,487 set to true. + tcp_keepalive + + If true, enable the periodic transmission of messages on + a connected socket. If the connected party fails to + respond to these messages, the connection is con- + sidered broken. This applies only to services with + endpoint_type set to streams and wait set to false. + + tcp_trace If true, and this is a nowait-type service, inetd logs *** *** 566,571 --- 575,581 inherit_env true max_con_rate-1 max_copies -1 +tcp_keepalive false tcp_trace false tcp_wrappersfalse
2009/470 tcp_keepalive For inetd Services
On Fri, Aug 28, 2009 at 11:12:37PM +0100, Andrew Gabriel wrote: This is quite different from any of the existing inetd configuration parameters - inetd doesn't currently allow manipulation of socket configuration parameters. But maybe it should. There's a large variety of potentially useful socket options to use, including IP_SEC_OPT (on listening sockets). Please can you describe a case where this is intended to be used? (I ask, because mostly whenever I do see it being used, the author misunderstood what it does and shouldn't have been using it.) The thread on networking-discuss made it clear: it's for use with protocols like TELNET and rlogin where there's no app-layer keepalive (compare to SSHv2, where we have app-layer keepalive features; see ClientAlive, ServerAlive, and related ssh_config/sshd_config options). As with all keepalives this is to... keep idle connections alive. Why do you intend to allow access to this socket parameter, but no others (such as SO_SNDBUF, SO_RCVBUF, etc)? I asked about that too. I'd like to see the keepalive timer interface set this way too. But I don't think this case is so incomplete without those that it should be TCR'ed to add them. I think this is a great OpenSolaris contribution story. [Note: I'm not part of the i-team.] Cheers, Nico --
LSARC/2009/472 - Crypt::CBC Perl Module
All, I am sponsoring this fast track for Spoorthy Shankarmurthy. The case directory contains this proposal and the man page for the component. I have set the timeout for Friday, September 4th, 2009. This case proposes to integrate the Crypt::CBC Perl module into a Minor release of Solaris. This Perl module is an implementation of the cryptographic cipher block chaining mode (CBC). In combination with a block cipher such as DES or IDEA, you can encrypt and decrypt messages of arbitrarily long length. Thanks, John -- next part -- An embedded and charset-unspecified text was scrubbed... Name: proposal.txt URL: http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20090828/d06538e4/attachment.txt
Crypt-CBC Perl Module [LSARC/2009/472 FastTrack timeout 09/04/2009]
Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Crypt-CBC Perl Module 1.2. Name of Document Author/Supplier: Author: Spoorthy Shankarmurthy 1.3 Date of This Document: 28 August, 2009 4. Technical Description Summary === This is Crypt::CBC, a Perl-only implementation of the cryptographic cipher block chaining mode (CBC). In combination with a block cipher such as Crypt::DES or Crypt::IDEA, you can encrypt and decrypt messages of arbitrarily long length. The encrypted messages are compatible with the encryption format used by BSSLeay. The latest version of Crypt-CBC is 2.30 and will be installed as SUNWperl-crypt-cbc package. Dependencies SUNWperl-crypt-des [ This package development is under progress ] Interfaces == Man pages are included. The SUNWperl-crypt-cbc package is Uncommitted. The remaining interfaces are Volatile. Exported Interfaces --- /usr/perl5/5.8.4/man/man3/Crypt::CBC.3 Man pages for the package Crypt-CBC Crypt::CBC perl module /usr/perl5/5.8.4/crypt-cbc/CBC.pm Imported Interfaces --- MD5 Not An Interface /usr/demo/crypt-cbc/Makefile.PL - Makefile perl file /usr/demo/crypt-cbc/README - Readme file for this package /usr/demo/crypt-cbc/eg/aes.pl - AES encrypt/decrypt files using CBC /usr/demo/crypt-cbc/eg/des/pl - DES encrypt/decrypt files using CBC /usr/demo/crypt-cbc/eg/idea/pl - IDEA encrypt/decrypt files using CBC /usr/demo/crypt-cbc/t/Blowfish.t /usr/demo/crypt-cbc/t/Blowfish_PP.t /usr/demo/crypt-cbc/t/CAST5.t /usr/demo/crypt-cbc/t/DES.t /usr/demo/crypt-cbc/t/IDEA.t /usr/demo/crypt-cbc/t/PCBC.t /usr/demo/crypt-cbc/t/Rijndael.t /usr/demo/crypt-cbc/t/Rijndael_compat.t /usr/demo/crypt-cbc/t/func.t /usr/demo/crypt-cbc/t/null_data.t /usr/demo/crypt-cbc/t/onezeropadding.t /usr/demo/crypt-cbc/t/parameters.t /usr/demo/crypt-cbc/t/preexisting.t Reference Documents === [1] http:://cpansearch.perl.org/src/LDS/Crypt-CBC-2.30 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: SFW 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open
2009/470 tcp_keepalive For inetd Services
On Fri, Aug 28, 2009 at 11:12:37PM +0100, Andrew Gabriel wrote: Liane Praza wrote: I'm filing this case for Gary as closed-approved-automatic, as it seems an obvious extension to existing interface. As usual, speak up if you'd like to see it promoted to a fasttrack. tcp_keepalive For inetd Services Gary Mills 08/27/2009 1. Summary The inetd restarter defines a set of properties to control the behaviour of the services it manages. This case adds the option `tcp_keepalive' to the inetd restarter. Setting this option enables the TCP keepalive facility for connections to services managed by inetd. It's needed because some services do not have the ability to enable this facility by themselves. This is quite different from any of the existing inetd configuration parameters - inetd doesn't currently allow manipulation of socket configuration parameters. Please can you describe a case where this is intended to be used? (I ask, because mostly whenever I do see it being used, the author misunderstood what it does and shouldn't have been using it.) Why do you intend to allow access to this socket parameter, but no others (such as SO_SNDBUF, SO_RCVBUF, etc)? We've been using the keepalive option for some time, both on Solaris 9 and Solaris 10, through a wrapper, only for telnet and rlogin. That's because we have a firewall that disconnects idle sessions after one hour. This works without complaints for HTTP connections but is extremely annoying for the few terminal connections that exist. The telnet and rlogin servers have no way to enable keepalives at any level. Yes, you can say that doing that is a misuse of the facility, although I'd prefer to call it a clever use. Bug 6263835, initiated by me, suggests adding the option to inetd so that the wrapper would no longer be necessary. My webrev is at: http://cr.opensolaris.org/~jgmills/ws-6263835/ Yes, there are many other TCP options that inetd could set. In fact, I expected that to be one of the objections. I didn't think that we wanted to make all of them available in the inetd configuration, unless we had some justification for doing that. In fact, there are so many of them that we'd have to devise a language for them, rather than adding all of them as separate options to inetd. I didn't want to open that can of worms. -- -Gary Mills--Unix Group--Computer and Network Services-
