[gentoo-user] MBR partition

[gentoo-user] MBR partition

[Joseph]

I'm configuring MBR partition for older disk and need to know what code to enter for boot partition.  
My BIOS is not EFI type.

-- 
Joseph

Re: [gentoo-user] MBR partition

[Joseph]

On 09/05/14 21:02, Joseph wrote:
>I'm configuring MBR partition for older disk and need to know what code to enter for boot partition.
>My BIOS is not EFI type.

My current configuration:
fdisk -l /dev/sda

Disk /dev/sda: 447.1 GiB, 480103981056 bytes, 937703088 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x021589e5

Device    Boot     Start       End    Blocks  Id System
/dev/sda1 *         2048    155647     76800  83 Linux
/dev/sda2         155648   4349951   2097152  82 Linux swap / Solaris
/dev/sda3        4349952 937703087 466676568  83 Linux

Does the sda1 has to start with "1" or 2048?  

-- 
Joseph

Re: [gentoo-user] MBR partition

[J. Roeleveld]

On 6 September 2014 05:10:59 CEST, Joseph <syscon780@gmail.com> wrote:
>On 09/05/14 21:02, Joseph wrote:
>>I'm configuring MBR partition for older disk and need to know what
>code to enter for boot partition.
>>My BIOS is not EFI type.
>
>My current configuration:
>fdisk -l /dev/sda
>
>Disk /dev/sda: 447.1 GiB, 480103981056 bytes, 937703088 sectors
>Units: sectors of 1 * 512 = 512 bytes
>Sector size (logical/physical): 512 bytes / 512 bytes
>I/O size (minimum/optimal): 512 bytes / 512 bytes
>Disklabel type: dos
>Disk identifier: 0x021589e5
>
>Device    Boot     Start       End    Blocks  Id System
>/dev/sda1 *         2048    155647     76800  83 Linux
>/dev/sda2         155648   4349951   2097152  82 Linux swap / Solaris
>/dev/sda3        4349952 937703087 466676568  83 Linux
>
>Does the sda1 has to start with "1" or 2048?  

This should work.
If, after following the handbook, it doesn't boot.
Please tell us what actually happens.

--
Joost
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-user] MBR partition

[Kerin Millar]

On 06/09/2014 04:10, Joseph wrote:
> On 09/05/14 21:02, Joseph wrote:
>> I'm configuring MBR partition for older disk and need to know what
>> code to enter for boot partition.
>> My BIOS is not EFI type.

Not that it particularly matters but a partition dedicated to /boot 
contains a Linux filesystem and, thus, 83 is appropriate.

>
> My current configuration:
> fdisk -l /dev/sda
>
> Disk /dev/sda: 447.1 GiB, 480103981056 bytes, 937703088 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: dos
> Disk identifier: 0x021589e5
>
> Device    Boot     Start       End    Blocks  Id System
> /dev/sda1 *         2048    155647     76800  83 Linux
> /dev/sda2         155648   4349951   2097152  82 Linux swap / Solaris
> /dev/sda3        4349952 937703087 466676568  83 Linux
>
> Does the sda1 has to start with "1" or 2048?

As of util-linux-2.18, partitions are aligned to 1 MiB boundaries by 
default, so as to avoid performance degradation on SSDs and advanced 
format drives [1].

Further, beginning at 2048 as opposed to 63 (in the manner of MS-DOS) 
provides more room for boot loaders such as grub to embed themselves.

To have the first sector be a partition boundary is impossible because 
that is the location of the MBR and the partition table.

In summary, let it be.

--Kerin

[1] https://bugs.gentoo.org/show_bug.cgi?id=304727
[2] https://en.wikipedia.org/wiki/Master_boot_record

Re: [gentoo-user] MBR partition

[Joseph]

On 09/06/14 07:15, Kerin Millar wrote:
>On 06/09/2014 04:10, Joseph wrote:
>> On 09/05/14 21:02, Joseph wrote:
>>> I'm configuring MBR partition for older disk and need to know what
>>> code to enter for boot partition.
>>> My BIOS is not EFI type.
>
>Not that it particularly matters but a partition dedicated to /boot
>contains a Linux filesystem and, thus, 83 is appropriate.
>
>>
>> My current configuration:
>> fdisk -l /dev/sda
>>
>> Disk /dev/sda: 447.1 GiB, 480103981056 bytes, 937703088 sectors
>> Units: sectors of 1 * 512 = 512 bytes
>> Sector size (logical/physical): 512 bytes / 512 bytes
>> I/O size (minimum/optimal): 512 bytes / 512 bytes
>> Disklabel type: dos
>> Disk identifier: 0x021589e5
>>
>> Device    Boot     Start       End    Blocks  Id System
>> /dev/sda1 *         2048    155647     76800  83 Linux
>> /dev/sda2         155648   4349951   2097152  82 Linux swap / Solaris
>> /dev/sda3        4349952 937703087 466676568  83 Linux
>>
>> Does the sda1 has to start with "1" or 2048?
>
>As of util-linux-2.18, partitions are aligned to 1 MiB boundaries by
>default, so as to avoid performance degradation on SSDs and advanced
>format drives [1].
>
>Further, beginning at 2048 as opposed to 63 (in the manner of MS-DOS)
>provides more room for boot loaders such as grub to embed themselves.
>
>To have the first sector be a partition boundary is impossible because
>that is the location of the MBR and the partition table.
>
>In summary, let it be.
>
>--Kerin

Thank you for the information.
I'll continue on Monday and let you know.  If it will not boot with sector starting at 2048, I will re-partition /boot sda1 to start at 63.

-- 
Joseph

[gentoo-user] Re: MBR partition

[James]

Joseph <syscon780 <at> gmail.com> writes:

> Thank you for the information.
> I'll continue on Monday and let you know.  If it will not boot with sector
starting at 2048, I will
> re-partition /boot sda1 to start at 63.


Take some time to research and reflect on your needs (desires?)
about which file system to use. (ext 2,4) is always popular and safe.
Some are very happy with BTRFS and there are many other interesting
choices (ZFS, XFS, etc etc)......

There is no best solution; but the EXT family offers tried and proven
options. YMMV.


hth,
James

Re: [gentoo-user] Re: MBR partition

[Dale]

James wrote:
> Joseph <syscon780 <at> gmail.com> writes:
>
>> Thank you for the information.
>> I'll continue on Monday and let you know.  If it will not boot with sector
> starting at 2048, I will
>> re-partition /boot sda1 to start at 63.
>
> Take some time to research and reflect on your needs (desires?)
> about which file system to use. (ext 2,4) is always popular and safe.
> Some are very happy with BTRFS and there are many other interesting
> choices (ZFS, XFS, etc etc)......
>
> There is no best solution; but the EXT family offers tried and proven
> options. YMMV.
>
>
> hth,
> James
>

I'm not sure if it is ZFS or XFS but I seem to recall one of those does
not like sudden shutdowns, such as a power failure.  Maybe that has
changed since I last tried whichever one it is that has that issue.  If
you have a UPS tho, shouldn't be so much of a problem, unless your power
supply goes out. 

Just a little heads up in case it matters. 

Oh, I use ext2 for /boot and ext4 for everything else, some of that on
top of LVM.  I switched from reiserfs a good while back, bit rot.  So
far, I been really pleased with ext4. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: MBR partition

[Alan McKinnon]

On 06/09/2014 14:48, Dale wrote:
> James wrote:
>> Joseph <syscon780 <at> gmail.com> writes:
>>
>>> Thank you for the information.
>>> I'll continue on Monday and let you know.  If it will not boot with sector
>> starting at 2048, I will
>>> re-partition /boot sda1 to start at 63.
>>
>> Take some time to research and reflect on your needs (desires?)
>> about which file system to use. (ext 2,4) is always popular and safe.
>> Some are very happy with BTRFS and there are many other interesting
>> choices (ZFS, XFS, etc etc)......
>>
>> There is no best solution; but the EXT family offers tried and proven
>> options. YMMV.
>>
>>
>> hth,
>> James
>>
> 
> I'm not sure if it is ZFS or XFS but I seem to recall one of those does
> not like sudden shutdowns, such as a power failure.  Maybe that has
> changed since I last tried whichever one it is that has that issue.  If
> you have a UPS tho, shouldn't be so much of a problem, unless your power
> supply goes out. 

XFS.

It was designed by SGI for their video rendeing workstations back in the
day and used very aggressive caching to get enormous throughput. It was
also brilliant at dealing with directories containing thousands of small
files - not unusual when dealing with video editing.

However, it was also designed for environments where the power is
guaranteed to never go off (which explains why they decided to go with
such aggressive caching). If you use it in environments where powerouts
are not guaranteed to not happen, well......



ZFS is the most resilient filesystem I've ever used, you can through the
bucket and kitchen sink at it and it really doesn't give a shit (it just
deals with it :-) )



> 
> Just a little heads up in case it matters. 
> 
> Oh, I use ext2 for /boot and ext4 for everything else, some of that on
> top of LVM.  I switched from reiserfs a good while back, bit rot.  So
> far, I been really pleased with ext4. 

Yeah, that's a pretty normal default setup, it performs well across the
boards for average desktop and server loads


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: MBR partition

[Rich Freeman]

On Sat, Sep 6, 2014 at 8:54 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>
> ZFS is the most resilient filesystem I've ever used, you can through the
> bucket and kitchen sink at it and it really doesn't give a shit (it just
> deals with it :-) )
>

Nothing wrong with ZFS itself, but keep in mind that ZFS on linux is
not the same as ZFS on Solaris as far as maturity goes.  I'll admit
that I'm a btrfs fan for a couple of reasons, but when it comes to
stability on linux I wouldn't put either in the same class as ext3, or
even ext4 (which is pretty mature now).

--
Rich

Re: [gentoo-user] Re: MBR partition

[Alan McKinnon]

On 06/09/2014 15:13, Rich Freeman wrote:
> On Sat, Sep 6, 2014 at 8:54 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>>
>> ZFS is the most resilient filesystem I've ever used, you can through the
>> bucket and kitchen sink at it and it really doesn't give a shit (it just
>> deals with it :-) )
>>
> 
> Nothing wrong with ZFS itself, but keep in mind that ZFS on linux is
> not the same as ZFS on Solaris as far as maturity goes.  I'll admit
> that I'm a btrfs fan for a couple of reasons, but when it comes to
> stability on linux I wouldn't put either in the same class as ext3, or
> even ext4 (which is pretty mature now).


I neglected to mention - I use ZFS on FreeBSD, haven't used ZFS on linux
enought o comment on that





-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: MBR partition

[Rich Freeman]

On Sat, Sep 6, 2014 at 10:05 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On 06/09/2014 15:13, Rich Freeman wrote:
>> On Sat, Sep 6, 2014 at 8:54 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>>>
>>> ZFS is the most resilient filesystem I've ever used, you can through the
>>> bucket and kitchen sink at it and it really doesn't give a shit (it just
>>> deals with it :-) )
>>>
>>
>> Nothing wrong with ZFS itself, but keep in mind that ZFS on linux is
>> not the same as ZFS on Solaris as far as maturity goes.  I'll admit
>> that I'm a btrfs fan for a couple of reasons, but when it comes to
>> stability on linux I wouldn't put either in the same class as ext3, or
>> even ext4 (which is pretty mature now).
>
>
> I neglected to mention - I use ZFS on FreeBSD, haven't used ZFS on linux
> enought o comment on that
>

I'm not an expert on ZFS, but I believe that it is considered more
stable on FreeBSD, since I believe they used the original CDDL sources
there.  It still hasn't been around for as long as it has been on
Solaris of course, but it is a bit more mainstream on BSD.

--
Rich

Re: [gentoo-user] Re: MBR partition

[Kerin Millar]

On 06/09/2014 13:54, Alan McKinnon wrote:
> On 06/09/2014 14:48, Dale wrote:
>> James wrote:
>>> Joseph <syscon780 <at> gmail.com> writes:
>>>
>>>> Thank you for the information.
>>>> I'll continue on Monday and let you know.  If it will not boot with sector
>>> starting at 2048, I will
>>>> re-partition /boot sda1 to start at 63.
>>>
>>> Take some time to research and reflect on your needs (desires?)
>>> about which file system to use. (ext 2,4) is always popular and safe.
>>> Some are very happy with BTRFS and there are many other interesting
>>> choices (ZFS, XFS, etc etc)......
>>>
>>> There is no best solution; but the EXT family offers tried and proven
>>> options. YMMV.
>>>
>>>
>>> hth,
>>> James
>>>
>>
>> I'm not sure if it is ZFS or XFS but I seem to recall one of those does
>> not like sudden shutdowns, such as a power failure.  Maybe that has
>> changed since I last tried whichever one it is that has that issue.  If
>> you have a UPS tho, shouldn't be so much of a problem, unless your power
>> supply goes out.
>
> XFS.
>
> It was designed by SGI for their video rendeing workstations back in the
> day and used very aggressive caching to get enormous throughput. It was
> also brilliant at dealing with directories containing thousands of small
> files - not unusual when dealing with video editing.
>
> However, it was also designed for environments where the power is
> guaranteed to never go off (which explains why they decided to go with
> such aggressive caching). If you use it in environments where powerouts
> are not guaranteed to not happen, well......

Well what? It's no less reliable than other filesystems that employ 
delayed allocation (any modern filesystem worth of note). Over recent 
years, I use both XFS and ext4 extensively in production and have found 
the former trumps the latter in reliability.

While I like them both, I predicate this assertion mainly on some of the 
silly bugs that I have seen crop up in the ext4 codebase and the 
unedifying commentary that has occasionally ensued. From reading the XFS 
list and my own experience, I have formed the opinion that the 
maintainers are more stringent in matters of QA and regression testing 
and more mature in matters of public debate. I also believe that 
regressions in stability are virtually unheard of, whereas regressions 
in performance are identified quickly and taken very seriously [1].

The worst thing I could say about XFS is that it was comparatively slow 
until the introduction of delayed logging (an idea taken from ext3). [2] 
[3]. Nowadays, it is on a par with ext4 and, in some cases, scales 
better. It is also one of the few filesystems besides ZFS that can 
dynamically allocate inodes.

>
>
>
> ZFS is the most resilient filesystem I've ever used, you can through the
> bucket and kitchen sink at it and it really doesn't give a shit (it just
> deals with it :-) )

While its design is intrinsically resilient - particularly its 
capability to protect against bitrot - I don't believe that ZFS on Linux 
is more reliable in practice than the filesystems included in the Linux 
kernel. Quite the contrary. Look at the issues labelled as "Bug" filed 
for both the SPL and ZFS projects. There are a considerable number of 
serious bugs that - to my mind - disqualify it for anything but hobbyist 
use and I take issue with the increasing tendency among the community to 
casually recommend it.

Here's my anecdotal experience of using it. My hosting company recently 
installed a dedicated backup server that was using ZFS on Linux. Its 
primary function was as an NFS server. It was very slow and repeatedly 
deadlocked under heavy load. On each occasion, the only remedy was for 
an engineer to perform a hard reboot. When I complained about it, I was 
told that they normally use FreeBSD but had opted for Linux because the 
former was not compatible with a fibre channel adapter that they needed 
to make use of. I then requested that the filesystem be changed to ext4, 
after which the server was rock solid.

Another experience I have is of helping someone resolve an issue where 
MySQL was not starting. It transpired that he was using ZFS and that it 
does not support native AIO. I supplied him with a workaround but 
sternly advised him to switch to a de-facto Linux filesystem if he 
valued his data and expected anything like decent performance from 
InnoDB. Speaking of which, XFS is a popular filesystem among 
knowledgeable MySQL hackers (such as Mark Callaghan) and DBAs alike.

For the time being, I think that there are other operating systems whose 
ZFS implementation is more robust.

--Kerin

[1] 
http://www.percona.com/blog/2012/03/15/ext4-vs-xfs-on-ssd/#comment-903938
[2] 
https://www.kernel.org/doc/Documentation/filesystems/xfs-delayed-logging-design.txt
[3] https://www.youtube.com/watch?v=FegjLbCnoBw

Re: [gentoo-user] Re: MBR partition

[Rich Freeman]

On Sat, Sep 6, 2014 at 4:54 PM, Kerin Millar <kerframil@fastmail.co.uk> wrote:
> From reading the XFS list and my own experience, I have formed the
> opinion that the maintainers are more stringent in matters of QA and
> regression testing and more mature in matters of public debate.

That doesn't surprise me.  One of the best tools for QA testing any
filesystem is xfs_test, which was, as is obvious from the name,
developed to stress xfs.  I know the btrfs devs use it heavily, though
it doesn't test all the more modern features of btrfs like
snapshotting, reflinks, send/receive, and so on.

I know the whole lkml debate about data=ordered didn't thrill me all
that much.  I'm a firm believer that no filesystem should eat your
data if it doesn't cleanly unmount.  I don't have a problem with
losing the last n seconds of changes because of write caching.  What I
do have a problem with is when after a crash a file contains something
other than the previous contents or the new contents, especially if a
failed append to a file ends up zeroing out the whole file or some
nonsense like that.

> It is also one of the few filesystems besides ZFS that can dynamically
> allocate inodes.
>

FWIW, btrfs also dynamically allocates inodes.  ZFS and btrfs are
fairly comparable in terms of capabilities, with each now having a few
features the other lacks.  Btrfs is definitely less mature though.

--
Rich

Re: [gentoo-user] Re: MBR partition

[Dale]

Kerin Millar wrote:
> On 06/09/2014 13:54, Alan McKinnon wrote:
>> On 06/09/2014 14:48, Dale wrote:
>>> James wrote:
>>>> Joseph <syscon780 <at> gmail.com> writes:
>>>>
>>>>> Thank you for the information.
>>>>> I'll continue on Monday and let you know.  If it will not boot
>>>>> with sector
>>>> starting at 2048, I will
>>>>> re-partition /boot sda1 to start at 63.
>>>>
>>>> Take some time to research and reflect on your needs (desires?)
>>>> about which file system to use. (ext 2,4) is always popular and safe.
>>>> Some are very happy with BTRFS and there are many other interesting
>>>> choices (ZFS, XFS, etc etc)......
>>>>
>>>> There is no best solution; but the EXT family offers tried and proven
>>>> options. YMMV.
>>>>
>>>>
>>>> hth,
>>>> James
>>>>
>>>
>>> I'm not sure if it is ZFS or XFS but I seem to recall one of those does
>>> not like sudden shutdowns, such as a power failure.  Maybe that has
>>> changed since I last tried whichever one it is that has that issue.  If
>>> you have a UPS tho, shouldn't be so much of a problem, unless your
>>> power
>>> supply goes out.
>>
>> XFS.
>>
>> It was designed by SGI for their video rendeing workstations back in the
>> day and used very aggressive caching to get enormous throughput. It was
>> also brilliant at dealing with directories containing thousands of small
>> files - not unusual when dealing with video editing.
>>
>> However, it was also designed for environments where the power is
>> guaranteed to never go off (which explains why they decided to go with
>> such aggressive caching). If you use it in environments where powerouts
>> are not guaranteed to not happen, well......
>
> Well what? It's no less reliable than other filesystems that employ
> delayed allocation (any modern filesystem worth of note). Over recent
> years, I use both XFS and ext4 extensively in production and have
> found the former trumps the latter in reliability.
>
> While I like them both, I predicate this assertion mainly on some of
> the silly bugs that I have seen crop up in the ext4 codebase and the
> unedifying commentary that has occasionally ensued. From reading the
> XFS list and my own experience, I have formed the opinion that the
> maintainers are more stringent in matters of QA and regression testing
> and more mature in matters of public debate. I also believe that
> regressions in stability are virtually unheard of, whereas regressions
> in performance are identified quickly and taken very seriously [1].
>
> The worst thing I could say about XFS is that it was comparatively
> slow until the introduction of delayed logging (an idea taken from
> ext3). [2] [3]. Nowadays, it is on a par with ext4 and, in some cases,
> scales better. It is also one of the few filesystems besides ZFS that
> can dynamically allocate inodes.
> <<SNIP>>
> --Kerin
>
> [1]
> http://www.percona.com/blog/2012/03/15/ext4-vs-xfs-on-ssd/#comment-903938
> [2]
> https://www.kernel.org/doc/Documentation/filesystems/xfs-delayed-logging-design.txt
> [3] https://www.youtube.com/watch?v=FegjLbCnoBw
>
>

The point I was making in my comment was about if the power fails
without a proper shutdown.  When I used it a long time ago, it worked
fine, until there was a sudden power loss.  That is when problems pop
up.  If a person has a UPS, should be good to go. 

Dale

:-)  :-)

Re: [gentoo-user] Re: MBR partition

[Kerin Millar]

On 07/09/2014 01:28, Dale wrote:
> Kerin Millar wrote:
>> On 06/09/2014 13:54, Alan McKinnon wrote:
>>> On 06/09/2014 14:48, Dale wrote:
>>>> James wrote:
>>>>> Joseph <syscon780 <at> gmail.com> writes:
>>>>>
>>>>>> Thank you for the information.
>>>>>> I'll continue on Monday and let you know.  If it will not boot
>>>>>> with sector
>>>>> starting at 2048, I will
>>>>>> re-partition /boot sda1 to start at 63.
>>>>>
>>>>> Take some time to research and reflect on your needs (desires?)
>>>>> about which file system to use. (ext 2,4) is always popular and safe.
>>>>> Some are very happy with BTRFS and there are many other interesting
>>>>> choices (ZFS, XFS, etc etc)......
>>>>>
>>>>> There is no best solution; but the EXT family offers tried and proven
>>>>> options. YMMV.
>>>>>
>>>>>
>>>>> hth,
>>>>> James
>>>>>
>>>>
>>>> I'm not sure if it is ZFS or XFS but I seem to recall one of those does
>>>> not like sudden shutdowns, such as a power failure.  Maybe that has
>>>> changed since I last tried whichever one it is that has that issue.  If
>>>> you have a UPS tho, shouldn't be so much of a problem, unless your
>>>> power
>>>> supply goes out.
>>>
>>> XFS.
>>>
>>> It was designed by SGI for their video rendeing workstations back in the
>>> day and used very aggressive caching to get enormous throughput. It was
>>> also brilliant at dealing with directories containing thousands of small
>>> files - not unusual when dealing with video editing.
>>>
>>> However, it was also designed for environments where the power is
>>> guaranteed to never go off (which explains why they decided to go with
>>> such aggressive caching). If you use it in environments where powerouts
>>> are not guaranteed to not happen, well......
>>
>> Well what? It's no less reliable than other filesystems that employ
>> delayed allocation (any modern filesystem worth of note). Over recent
>> years, I use both XFS and ext4 extensively in production and have
>> found the former trumps the latter in reliability.
>>
>> While I like them both, I predicate this assertion mainly on some of
>> the silly bugs that I have seen crop up in the ext4 codebase and the
>> unedifying commentary that has occasionally ensued. From reading the
>> XFS list and my own experience, I have formed the opinion that the
>> maintainers are more stringent in matters of QA and regression testing
>> and more mature in matters of public debate. I also believe that
>> regressions in stability are virtually unheard of, whereas regressions
>> in performance are identified quickly and taken very seriously [1].
>>
>> The worst thing I could say about XFS is that it was comparatively
>> slow until the introduction of delayed logging (an idea taken from
>> ext3). [2] [3]. Nowadays, it is on a par with ext4 and, in some cases,
>> scales better. It is also one of the few filesystems besides ZFS that
>> can dynamically allocate inodes.
>> <<SNIP>>
>> --Kerin
>>
>> [1]
>> http://www.percona.com/blog/2012/03/15/ext4-vs-xfs-on-ssd/#comment-903938
>> [2]
>> https://www.kernel.org/doc/Documentation/filesystems/xfs-delayed-logging-design.txt
>> [3] https://www.youtube.com/watch?v=FegjLbCnoBw
>>
>>
>
> The point I was making in my comment was about if the power fails
> without a proper shutdown.  When I used it a long time ago, it worked
> fine, until there was a sudden power loss.  That is when problems pop
> up.  If a person has a UPS, should be good to go.

The point I was making is that there is not a shred of evidence to 
suggest that XFS is any less resilient in this scenario than newer 
filesystems employing delayed allocation such as ext4, btrfs and ZFS. 
What I take issue with is that people continue to single XFS out for 
criticism, regardless. Let XFS be judged as it it stands today, just as 
any other actively developed filesystem should be.

Filesystem implementations are not set in stone. Just as ext4 developers 
had to resolve certain engineering challenges raised by the use of 
delayed allocation, so have XFS developers had to do the same before 
them [1].

Arguments generally critical of the use of delayed allocation where 
power loss is a likely event would hold water. Fortunately, options 
remain for such a scenario (ext3, ext4 + nodelalloc).

--Kerin

[1] 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7d4fb40

Re: [gentoo-user] Re: MBR partition

[Dale]

Kerin Millar wrote:
> On 07/09/2014 01:28, Dale wrote:
>> Kerin Millar wrote:
>>> On 06/09/2014 13:54, Alan McKinnon wrote:
>>>> On 06/09/2014 14:48, Dale wrote:
>>>>> James wrote:
>>>>>> Joseph <syscon780 <at> gmail.com> writes:
>>>>>>
>>>>>>> Thank you for the information.
>>>>>>> I'll continue on Monday and let you know.  If it will not boot
>>>>>>> with sector
>>>>>> starting at 2048, I will
>>>>>>> re-partition /boot sda1 to start at 63.
>>>>>>
>>>>>> Take some time to research and reflect on your needs (desires?)
>>>>>> about which file system to use. (ext 2,4) is always popular and
>>>>>> safe.
>>>>>> Some are very happy with BTRFS and there are many other interesting
>>>>>> choices (ZFS, XFS, etc etc)......
>>>>>>
>>>>>> There is no best solution; but the EXT family offers tried and
>>>>>> proven
>>>>>> options. YMMV.
>>>>>>
>>>>>>
>>>>>> hth,
>>>>>> James
>>>>>>
>>>>>
>>>>> I'm not sure if it is ZFS or XFS but I seem to recall one of those
>>>>> does
>>>>> not like sudden shutdowns, such as a power failure.  Maybe that has
>>>>> changed since I last tried whichever one it is that has that
>>>>> issue.  If
>>>>> you have a UPS tho, shouldn't be so much of a problem, unless your
>>>>> power
>>>>> supply goes out.
>>>>
>>>> XFS.
>>>>
>>>> It was designed by SGI for their video rendeing workstations back
>>>> in the
>>>> day and used very aggressive caching to get enormous throughput. It
>>>> was
>>>> also brilliant at dealing with directories containing thousands of
>>>> small
>>>> files - not unusual when dealing with video editing.
>>>>
>>>> However, it was also designed for environments where the power is
>>>> guaranteed to never go off (which explains why they decided to go with
>>>> such aggressive caching). If you use it in environments where
>>>> powerouts
>>>> are not guaranteed to not happen, well......
>>>
>>> Well what? It's no less reliable than other filesystems that employ
>>> delayed allocation (any modern filesystem worth of note). Over recent
>>> years, I use both XFS and ext4 extensively in production and have
>>> found the former trumps the latter in reliability.
>>>
>>> While I like them both, I predicate this assertion mainly on some of
>>> the silly bugs that I have seen crop up in the ext4 codebase and the
>>> unedifying commentary that has occasionally ensued. From reading the
>>> XFS list and my own experience, I have formed the opinion that the
>>> maintainers are more stringent in matters of QA and regression testing
>>> and more mature in matters of public debate. I also believe that
>>> regressions in stability are virtually unheard of, whereas regressions
>>> in performance are identified quickly and taken very seriously [1].
>>>
>>> The worst thing I could say about XFS is that it was comparatively
>>> slow until the introduction of delayed logging (an idea taken from
>>> ext3). [2] [3]. Nowadays, it is on a par with ext4 and, in some cases,
>>> scales better. It is also one of the few filesystems besides ZFS that
>>> can dynamically allocate inodes.
>>> <<SNIP>>
>>> --Kerin
>>>
>>> [1]
>>> http://www.percona.com/blog/2012/03/15/ext4-vs-xfs-on-ssd/#comment-903938
>>>
>>> [2]
>>> https://www.kernel.org/doc/Documentation/filesystems/xfs-delayed-logging-design.txt
>>>
>>> [3] https://www.youtube.com/watch?v=FegjLbCnoBw
>>>
>>>
>>
>> The point I was making in my comment was about if the power fails
>> without a proper shutdown.  When I used it a long time ago, it worked
>> fine, until there was a sudden power loss.  That is when problems pop
>> up.  If a person has a UPS, should be good to go.
>
> The point I was making is that there is not a shred of evidence to
> suggest that XFS is any less resilient in this scenario than newer
> filesystems employing delayed allocation such as ext4, btrfs and ZFS.
> What I take issue with is that people continue to single XFS out for
> criticism, regardless. Let XFS be judged as it it stands today, just
> as any other actively developed filesystem should be.
>
> Filesystem implementations are not set in stone. Just as ext4
> developers had to resolve certain engineering challenges raised by the
> use of delayed allocation, so have XFS developers had to do the same
> before them [1].
>
> Arguments generally critical of the use of delayed allocation where
> power loss is a likely event would hold water. Fortunately, options
> remain for such a scenario (ext3, ext4 + nodelalloc).
>
> --Kerin
>
> [1]
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7d4fb40
>
>

Which is why I said that the issue could have changed since I last used
that file system.  What I learned is this, every time there was a sudden
power fail, it was unrecoverable.  I ended up reinstalling the OS.  That
is why I posted what I did.   Still, the point is this, if the OP is
going to use the file system that had that issue, research first to make
sure they are prepared for what may still be a side effect or that is is
no longer a problem now.  Every file system there is has something
negative.  It's up to us to find out if that negative can or will apply
to us.  Having the info is better than not having at all.  I wish I knew
that before I tried XFS before. 

I might add, I've had a few sudden power fails on systems with ext4. 
What I have not had yet was a unrecoverable file system like I had with
XFS.  Maybe XFS is improved now but even recently, ext4 didn't seem to
have that issue, at least on the system I was using it on.  I also have
no plans to try XFS again even tho I have a UPS now. 

Now that the OP has info that he/she may not have had before, they can
make a more informed decision. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: MBR partition

[Thanasis]

on 09/06/2014 03:48 PM Dale wrote the following:

>
> I'm not sure if it is ZFS or XFS but I seem to recall one of those does
> not like sudden shutdowns, such as a power failure.

XFS does not like sudden shutdowns

Re: [gentoo-user] SUCCESS! Re: MBR partition

[Joseph]

On 09/06/14 11:49, James wrote:
>Joseph <syscon780 <at> gmail.com> writes:
>
>> Thank you for the information.
>> I'll continue on Monday and let you know.  If it will not boot with sector
>starting at 2048, I will
>> re-partition /boot sda1 to start at 63.
>
>
>Take some time to research and reflect on your needs (desires?)
>about which file system to use. (ext 2,4) is always popular and safe.
>Some are very happy with BTRFS and there are many other interesting
>choices (ZFS, XFS, etc etc)......
>
>There is no best solution; but the EXT family offers tried and proven
>options. YMMV.
>
>
>hth,
>James

After two days of fighting with it, I was able to get it to work.
It seems to me GPT is not compatible with my old BIOS after all.  Using MBR and an old legacy grub worked.
The fdisk partitioned the /boot partition sda1 starting from 2048 and it worked without any problems. 

-- 
Joseph

[gentoo-user] Re: SUCCESS! Re: MBR partition

[James]

Joseph <syscon780 <at> gmail.com> writes:


> After two days of fighting with it, I was able to get it to work.
> It seems to me GPT is not compatible with my old BIOS after all.  
> Using MBR and an old legacy grub worked.
> The fdisk partitioned the /boot partition sda1 starting from 2048 and it 
> worked without any problems. 


VERY COOL!
Gentoo is worth the effort. Make sure you have backups and some folks build
binary packages for a variety of reason. Don't hesitate to ask for help.
The Gentoo wiki is getting better and better. It's a place for folks to
contribute to the documentation, when they are comfortable with that.

enjoy,
James

Re: [gentoo-user] MBR partition

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 347 bytes --]

On Sat, 6 Sep 2014 04:44:56 -0600, Joseph wrote:

> I'll continue on Monday and let you know.  If it will not boot with
> sector starting at 2048, I will re-partition /boot sda1 to start at 63.

Don't even think about aligning partitions like that on an SSD.


-- 
Neil Bothwick

No, you *can't* call 999 now. I'm downloading my mail.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] MBR partition

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 509 bytes --]

On Saturday 06 Sep 2014 15:42:32 Neil Bothwick wrote:
> On Sat, 6 Sep 2014 04:44:56 -0600, Joseph wrote:
> > I'll continue on Monday and let you know.  If it will not boot with
> > sector starting at 2048, I will re-partition /boot sda1 to start at 63.
> 
> Don't even think about aligning partitions like that on an SSD.

Why do you want to move it to sector 63?  Leave exactly where it is and you 
will not have any problems installing and booting with GRUB2 or GRUB legacy.

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[gentoo-user] Re: MBR partition

[James]

Joseph <syscon780 <at> gmail.com> writes:


> I'm configuring MBR partition for older disk and need to know what code 
> to enter for boot partition.  My BIOS is not EFI type.


Just to ensure that you have made your decisions based on good information,
I wanted to clarify something about bios. Vendors often release newer or
updated bios codes very spedicfic to a particular motherboard. These updated
bios offerings, if they exist, may or many not allow you to boot and use GPT
(EFI) etc.

Neil pointed out an option I'm not familiar with. Another option is to use
linuxbios (now called coreboot)[1]. If you do decide to try coreboot
to upgrade your bios, do your own research and find out if it is a valid
(possible) solution for you [2].

I mention this to complete and clarify the information I gave you, as
best as I can. Coreboot is an excellent project that is 'good to know'
knowledge, even if you choose otherwise.


James

[1] http://www.coreboot.org/Welcome_to_coreboot

[2] http://www.coreboot.org/Supported_Motherboards

Re: [gentoo-user] Re: MBR partition

[Dale]

James wrote:
> Joseph <syscon780 <at> gmail.com> writes:
>
>
>> I'm configuring MBR partition for older disk and need to know what code 
>> to enter for boot partition.  My BIOS is not EFI type.
>
> Just to ensure that you have made your decisions based on good information,
> I wanted to clarify something about bios. Vendors often release newer or
> updated bios codes very spedicfic to a particular motherboard. These updated
> bios offerings, if they exist, may or many not allow you to boot and use GPT
> (EFI) etc.
>
> Neil pointed out an option I'm not familiar with. Another option is to use
> linuxbios (now called coreboot)[1]. If you do decide to try coreboot
> to upgrade your bios, do your own research and find out if it is a valid
> (possible) solution for you [2].
>
> I mention this to complete and clarify the information I gave you, as
> best as I can. Coreboot is an excellent project that is 'good to know'
> knowledge, even if you choose otherwise.
>
>
> James
>
> [1] http://www.coreboot.org/Welcome_to_coreboot
>
> [2] http://www.coreboot.org/Supported_Motherboards
>

If I might add this, some newer mobos don't even need a OS at all.  On
my Gigabyte, I hit the power button, then one of the function keys and
have the new BIOS file on a USB stick.  It sees the file, installs it
and it reboots from there.  I've only done it once that I recall but I
do recall it didn't require any OS at all.  I don't know if this is a
option for the OP tho. 

Dale

:-)  :-) 

Re: [gentoo-user] MBR partition

[Alan McKinnon]

On 06/09/2014 05:02, Joseph wrote:
> I'm configuring MBR partition for older disk and need to know what code
> to enter for boot partition.  My BIOS is not EFI type.
> 


There is no such thing as an MBR partition. Please clarify.

The MBR is the first sector of the disk. It simply exists and you use it
as such.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] MBR partition

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 853 bytes --]

On Saturday 06 Sep 2014 13:49:27 Alan McKinnon wrote:
> On 06/09/2014 05:02, Joseph wrote:
> > I'm configuring MBR partition for older disk and need to know what code
> > to enter for boot partition.  My BIOS is not EFI type.
> 
> There is no such thing as an MBR partition. Please clarify.
> 
> The MBR is the first sector of the disk. It simply exists and you use it
> as such.

I think the OP is meant to say that he is formatting an older disk (I'm 
guessing less than 2TB) with a DOS partition table for the purpose of booting 
with an MBR (as opposed to UEFI).

Of course I am reading between the lines here, because the OP has not 
formulated the question clearly enough for me to know what kind of code he is 
referring to (the whole PC is full of ... code) and where does he intend to 
enter such code.

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] MBR partition

[Alan McKinnon]

On 07/09/2014 13:44, Mick wrote:
> On Saturday 06 Sep 2014 13:49:27 Alan McKinnon wrote:
>> On 06/09/2014 05:02, Joseph wrote:
>>> I'm configuring MBR partition for older disk and need to know what code
>>> to enter for boot partition.  My BIOS is not EFI type.
>>
>> There is no such thing as an MBR partition. Please clarify.
>>
>> The MBR is the first sector of the disk. It simply exists and you use it
>> as such.
> 
> I think the OP is meant to say that he is formatting an older disk (I'm 
> guessing less than 2TB) with a DOS partition table for the purpose of booting 
> with an MBR (as opposed to UEFI).
> 
> Of course I am reading between the lines here, because the OP has not 
> formulated the question clearly enough for me to know what kind of code he is 
> referring to (the whole PC is full of ... code) and where does he intend to 
> enter such code.
> 


I agree, and I figured the same. Still waiting for his answer.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] MBR partition

[Peter Humphrey]

On Sunday 07 September 2014 14:25:50 Alan McKinnon wrote:
> On 07/09/2014 13:44, Mick wrote:
> > On Saturday 06 Sep 2014 13:49:27 Alan McKinnon wrote:
> >> On 06/09/2014 05:02, Joseph wrote:
> >>> I'm configuring MBR partition for older disk and need to know what code
> >>> to enter for boot partition.  My BIOS is not EFI type.
> >> 
> >> There is no such thing as an MBR partition. Please clarify.
> >> 
> >> The MBR is the first sector of the disk. It simply exists and you use it
> >> as such.
> > 
> > I think the OP is meant to say that he is formatting an older disk (I'm
> > guessing less than 2TB) with a DOS partition table for the purpose of
> > booting with an MBR (as opposed to UEFI).
> > 
> > Of course I am reading between the lines here, because the OP has not
> > formulated the question clearly enough for me to know what kind of code he
> > is referring to (the whole PC is full of ... code) and where does he
> > intend to enter such code.
> 
> I agree, and I figured the same. Still waiting for his answer.

He said he'd resume after the weekend, so don't hold your breath just yet...

-- 
Regards
Peter