Final Call ... XenServer Boot Media
-
@scottalanmiller said in Final Call ... XenServer Boot Media:
@BRRABill said in Final Call ... XenServer Boot Media:
@scottalanmiller said in Final Call ... XenServer Boot Media:
@BRRABill said in Final Call ... XenServer Boot Media:
du says it is really 48K
Yes, it is a sparse file. Very small.
As I mentioned it is a bug of some sort, somewhere.
Seems like it happens across platforms.
What is a bug?
" On several versions of RedHat Enterprise Linux and Fedora, corruption in this file can cause the size to be misrepresented. This has no effect on the real space used by the file, as reported by the du command."
-
@Dashrender said in Final Call ... XenServer Boot Media:
@scottalanmiller said in Final Call ... XenServer Boot Media:
@BRRABill said in Final Call ... XenServer Boot Media:
If you are trying to tell me that this ONE system that is set up like this is the norm, and all the others are incorrect or just plain dumb, well, then, fine.
General good practice (rule of thumb, NOT best practice) is to "always" use UTC for all service based systems (servers and similar devices.) End users set time for the user, not the system, so this does not normally apply to end users. But we've always set all servers to UTC since the late 1990s. It protects against time bugs from the 1990s, it makes logs way clearer, it keeps people like @Minion-Queen from causing time problems from getting confused on time zones, it lets teams in different regions work together seamlessly. Yes, UTC on everything for IT.
Huh, first time I've ever heard this - even being in SW for better than 5 years.
It is not common at all in the SMB because the SMB rarely does logging. When you get into logging it is almost always done in UTC on the backend. and the user can select their own timezone for their GUI to report if desired.
-
@BRRABill said in Final Call ... XenServer Boot Media:
@scottalanmiller said in Final Call ... XenServer Boot Media:
@BRRABill said in Final Call ... XenServer Boot Media:
@scottalanmiller said in Final Call ... XenServer Boot Media:
@BRRABill said in Final Call ... XenServer Boot Media:
du says it is really 48K
Yes, it is a sparse file. Very small.
As I mentioned it is a bug of some sort, somewhere.
Seems like it happens across platforms.
What is a bug?
" On several versions of RedHat Enterprise Linux and Fedora, corruption in this file can cause the size to be misrepresented. This has no effect on the real space used by the file, as reported by the du command."
Who said that? That's totally wrong. It's space is not misrepresented, it's not a bug. Someone is confused. ls and du show different things, both are correct.
-
@JaredBusch said in Final Call ... XenServer Boot Media:
@Dashrender said in Final Call ... XenServer Boot Media:
@scottalanmiller said in Final Call ... XenServer Boot Media:
@BRRABill said in Final Call ... XenServer Boot Media:
If you are trying to tell me that this ONE system that is set up like this is the norm, and all the others are incorrect or just plain dumb, well, then, fine.
General good practice (rule of thumb, NOT best practice) is to "always" use UTC for all service based systems (servers and similar devices.) End users set time for the user, not the system, so this does not normally apply to end users. But we've always set all servers to UTC since the late 1990s. It protects against time bugs from the 1990s, it makes logs way clearer, it keeps people like @Minion-Queen from causing time problems from getting confused on time zones, it lets teams in different regions work together seamlessly. Yes, UTC on everything for IT.
Huh, first time I've ever heard this - even being in SW for better than 5 years.
It is not common at all in the SMB because the SMB rarely does logging. When you get into logging it is almost always done in UTC on the backend. and the user can select their own timezone for their GUI to report if desired.
Yeah, it's not common. Sadly. But even without logging, it's useful. If you have multiple time zones to support, deal with remote access, etc. Logging really pushes it, but it is hardly the only thing. We did it more than a decade before we did central logging. It's a good practice (for most companies, again not a best practice, but should be considered for your use case) but not at all a common one.
-
@scottalanmiller said
" On several versions of RedHat Enterprise Linux and Fedora, corruption in this file can cause the size to be misrepresented. This has no effect on the real space used by the file, as reported by the du command."
Who said that? That's totally wrong. It's space is not misrepresented, it's not a bug. Someone is confused. ls and du show different things, both are correct.
Also, in the XS bug link I posted above.
-
A good definition of why it is not a bug:
http://www.noah.org/wiki/Lastlog_is_gigantic -
@BRRABill said in Final Call ... XenServer Boot Media:
@scottalanmiller said
" On several versions of RedHat Enterprise Linux and Fedora, corruption in this file can cause the size to be misrepresented. This has no effect on the real space used by the file, as reported by the du command."
Who said that? That's totally wrong. It's space is not misrepresented, it's not a bug. Someone is confused. ls and du show different things, both are correct.
Also, in the XS bug link I posted above.
I feel that that bug report is in error. This is not a bug, it is intentional and purposeful. It's well known to Linux admins, if they both showed the same size, it would be a bug.
-
@scottalanmiller said in Final Call ... XenServer Boot Media:
@BRRABill said in Final Call ... XenServer Boot Media:
@scottalanmiller said
" On several versions of RedHat Enterprise Linux and Fedora, corruption in this file can cause the size to be misrepresented. This has no effect on the real space used by the file, as reported by the du command."
Who said that? That's totally wrong. It's space is not misrepresented, it's not a bug. Someone is confused. ls and du show different things, both are correct.
Also, in the XS bug link I posted above.
I feel that that bug report is in error. This is not a bug, it is intentional and purposeful. It's well known to Linux admins, if they both showed the same size, it would be a bug.
Stupid Internet.
-
@BRRABill said in Final Call ... XenServer Boot Media:
BTW, here is the directory this morning.
Apparently it CREATES the files each day, but does nothing with them.
There is still that 38M lastlog file, but I think that is a bug in XS7. (Or Linux itself.)
https://bugs.xenserver.org/browse/XSO-534That's just a fake bug report from someone who didn't know Linux logging a bug because they were confused. The first comment answers why the reporter is confused. The bug is not assigned because there isn't any bug.
-
@BRRABill said in Final Call ... XenServer Boot Media:
@scottalanmiller said in Final Call ... XenServer Boot Media:
@BRRABill said in Final Call ... XenServer Boot Media:
@scottalanmiller said
" On several versions of RedHat Enterprise Linux and Fedora, corruption in this file can cause the size to be misrepresented. This has no effect on the real space used by the file, as reported by the du command."
Who said that? That's totally wrong. It's space is not misrepresented, it's not a bug. Someone is confused. ls and du show different things, both are correct.
Also, in the XS bug link I posted above.
I feel that that bug report is in error. This is not a bug, it is intentional and purposeful. It's well known to Linux admins, if they both showed the same size, it would be a bug.
Stupid Internet.
This is one of those "searching on it isn't useful, you have to study it in a structured way" to learn about it properly.
-
@scottalanmiller said
That's just a fake bug report from someone who didn't know Linux logging a bug because they were confused. The first comment answers why the reporter is confused. The bug is not assigned because there isn't any bug.
Ahhh, you have to log in to read comments.
-
@BRRABill said in Final Call ... XenServer Boot Media:
@scottalanmiller said
That's just a fake bug report from someone who didn't know Linux logging a bug because they were confused. The first comment answers why the reporter is confused. The bug is not assigned because there isn't any bug.
Ahhh, you have to log in to read comments.
Oh, I must be logged in by default.
-
I added sparse files and lastlog to the SAM Linux guide so that I remember to cover them in a upcoming installment.
-
@scottalanmiller said in Final Call ... XenServer Boot Media:
I added sparse files and lastlog to the SAM Linux guide so that I remember to cover them in a upcoming installment.
You are going to have to make a chapter called BRRABill Questions/Requests.
